Re: Why is there no tab "Update" in Java Control Panel? Install "Updater" separately?

On Oct 17, 5:36 am, g...@osgitest.org (Gianni Galore) wrote:


ab "Update".


On my Linux 64b box with Java 6u22 the control panel has an option for
whether Java updates happen automatically, upon prompt or manually
only.

--
Lew

e levels of function calling) where a value
can be updated directly by the called function.

But in ordinary language, a reference is:
- A citation of prior art, listing title of book or journal and
   enough additional information to find the article or book in a
   library. (Used in a new article/book that cites information from
   the prior art.)
- A letter attesting to a claim that somebody is of good quality,
   such as does good work and/or is of good moral character. (Used
   when applying for a job or a security clearance or housing etc.)

So instead of arguing whether C++ or Java uses the word
"correctly", when in fact *neither* does, best to avoid the word
entirely.

For what C++ passes, what the Lisp Machine called locatives, we
should use the Common Lisp jargon "place". Tell the function the
*place* where it is allowed to make references despite the fact
that *place* is in a higher-up space hence normally is forbidden
for access by the called function.
  Place = mutable cell.
  Locative = mechanism by which a place is passed to a function.
All the application programmer cares about is that the function
knows the place; the application programmer needn't know the
mechanism; hence my preference for "place" instead of "locative" in
API documentation.

For what Java passes, we could call it a "handle", because it's
more than just a pointer (machine address), it's a tagged pointer,
something that identifies both the machine address and the type of
data to be found there, by a tag accompanying the machine address
and/or by inspection of what is seen in the target. Likewise Lisp
pointers should also be called "handles" rather than "pointers".

For what C passes, that's just a machine address, with no type info
at runtime, so it's a "pointer". (And with casting to/from void*,
even the compiletime typing isn't really enforced.)
  int x = 5;
  int* px = &x;
  void* pv = px;
  double* pf = pv;
  double y = sqrt(*pf);
Untested. Did I get all that correct? I'm not really expert at C.

BTW many years ago, before Common Lisp, I made a try at designing a
new kind of Lisp where all parameters were places/locatives, even
when a computed value was being passed (the place within the stack
where that temporary value appears would be passed). It would be
the responsibility of the called function to fetch the old value
from that place if it was needed, and/or store the updated value
there before returning. It would be the responsibility of the
application programmer not to waste CPU cycles by passing a
temporary value to a function that was going to change it (and then
after return the caller has no way to make any use of that updated
value). In this way, SETF macros would never be needed. Instead of:
  (setf (car x) 5) ==macroExpand=> (let ((val 5)) (rplaca x val) val)
with my system we could just write
  (setq (car x) 5)
and it would work as-is, compiling code to use the locative to the
CAR of whatever x was at the time. But I was busy with other stuff
and never developed the idea much, and then discovered Common Lisp
with SETF macros and got lazy and just adapted to SETF.

Now I realize that one of the principles of OO, namely that places
can be hidden from the outside, requiring a method call to view
and/or set them, is often a good safety precaution, to protect
against disrupting data structures to be invalid (with respect to
the usual algorithms for them), thus to prevent the occurrance of
really hard-to-diagnose bugs. So now each ADT has a formal API
which is the *only* way any foreign code is allowed to
examine/modify the structures per the ADT, and the idea of passing
a locative (to a place within your data structure) to somebody who
may then modify that place any time it wants, thereby potentially
invalidating your data structure, so that *your* code breaks
because of what the other code did to your data, seems way too
dangerous.