Re: WOA, Building a Login form
Re: WOA, Building a Login form
- Subject: Re: WOA, Building a Login form
- From: Drew Thoeni <email@hidden>
- Date: Sun, 3 Apr 2005 21:45:45 -0400
Though this is a conversation between Ondra and I, and it is about
Java, not WO, I am posting it back to the list for the reference of
other newbies who might find themselves as the same place as I did.
Ondra's comments where helpful.
If you have a firm grasp of Java variable and object handling, skip
this.
Drew
On Apr 3, 2005, at 8:03 PM, Ondra Cada wrote:
Drew,
(note: I am not quite sure how many list readers may consider this
interesting. I answer offlist since you wrote me offlist, but do
please feel free to return this to the list, including any quotation
of my message, whenever you feel it appropriate.)
On 4.4.2005, at 1:38, Drew Thoeni wrote:
Thanks for spending the time explaining this. I was mistaken in my
understanding of how the references worked. I had assumed, that
since, when a=b, if you change a, b will reflect this change. That
appears to be true. But, my assumption extended to "if a is removed,
the b will be too." Clearly not the case as you explain. If I
understand this correctly now, both a and b exist and have pointers
to the same address space. But, when a is removed, b still has a
pointer to that address space. So, I assume, a will be garbage
collected but the address space it pointed to (and b still points to)
will stay because b still references it.
Correct?
Thanks again for the Java 101 lesson. This is the problem with
teaching yourself things. You sometimes miss the basics and you don't
easily know when you do.
That's the problem with Java: it is kinda obscure. Everybody should
learn Objective C :)))
Well, I must admit I do not quite follow your reasoning, but the thing
is pretty simple:
(i) an object is a block of bytes in memory (whose format is
well-known)
(ii) a variable--an object reference--is just an address (of some
object--the block of bytes)
That's all.
For some specific questions:
when a=b, if you change a, b will reflect this change
Never ever. Generally, the assigment changes its left side, leaving
whatever at the right of = completely unchanged.
if a is removed, the b will be too
If you are speaking of variables: they are *never ever* removed in
this sense (local variables are removed at the end of the appropriate
block, instance variables are removed when the object which contains
them is removed, of course, but that's another story).
The garbase collector removes objects only. It does that with objects,
which are no more referenced by any variable.
both a and b exist and have pointers to the same address space
Right. Perhaps a bit more precisely, "both variables, a and b, exists,
and *are* pointer to the same address" (in the same address space,
right--well I think we don't need to complicate things by bringing the
idea of more different address spaces here: true enough, they exist,
but they do not have *anything* to do with the problem we are
discussing now. From the point of view of one process--say, one
WebObjects application--there is only one address space, and we can
forget other ones).
when a is removed, b still has a pointer to that address space
Well... the variable a is (in our example) *not* removed. Its
*content* changes. The variable exists, but does no more contain the
address of the object (block of bytes) A -- therefore, (presumed no
other variable contains its address), the object will be removed in
future automatically by the garbage collector.
In this case, the variable (the address) survives the object--but
does, at the moment, contain *a different* address. That's why the
object may perish whilst the variable may survive: they have no more
*anything* common.
a will be garbage collected but the address space it pointed to (and
b still points to) will stay because b still references it
Well... kind of.
A (the uppercase, the object!) will be garbage collected -- since
there is no variable anymore which would contain its address.
a (the lowercase, the variable) still exists, but it contains a
different address, having thus no more *anything* to do with A.
As for B (the uppercase, the object): it is now referenced by two
variables, both a and b. Therefore, it will stay. To perish, *both* a
and b would have to get a different value. For example:
a=null;
// now B still lives, since b contains its address
b=null;
// at this moment or later B dies, since *no* variable at all contains
its address anymore
Do you follow? Just forget the hi-level stuff, the rules are simple:
- an object is a chunk of bytes in memory;
- a variable is an adress, which points to the chunk.
Far as there is any variable which contains the address of a concrete
chunk, the object lives. When there is no variable containing the
address, the object at that address dies (not immediately, but
somewhat later--when the garbage collector decides so).
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden