#become: and #oneWayBecome:

Hi,

    reading the method comment of #oneWayBecome: it mentions about
the efficience of the implementation.
       
        I quote:

"[SNIP]
This method should be used with care, but is some what less
dangerous than #become:, as it does not affect existing users of
anObject. Currently the implementation is not as efficient as #become:."

        What kind of efficience does it refers?

        I'm using #oneWayBecome: to transform stubs (Subclasses of
ProtoObject) into concrete objects, the stubs represents "external
objects" which are loaded at demand.

        But i'm not very sure about the "pointing" of the objects.

        E.g.
        objectA (concrete)
        otub1 (of objectB)
        stub2 (of objectA)
        stub3 (of objectA)

        If stub2 becomes the concrete objectA, so all what where pointing
to stub2 now points to objectA. If I want to preserve identity and
contents and objectA, when stub3 becomes the existing objectA it
should do it using #oneWayBecome:, am I right?

        What should I do if I want that all what points to anStub points to
nil?

        Thanks in advance.


--
Esteban A. Maringolo
[hidden email]

On Wed, 12 Jan 2005 10:44:55 -0300, Esteban A. Maringolo  
<[hidden email]> wrote:

> objectA (concrete)
> otub1 (of objectB)
> stub2 (of objectA)
> stub3 (of objectA)
>
> If stub2 becomes the concrete objectA, so all what where pointing to  
> stub2 now points to objectA. If I want to preserve identity and contents  
> and objectA, when stub3 becomes the existing objectA it should do it  
> using #oneWayBecome:, am I right?

What you want to do is probably to use #oneWayBecome: and not #become:.  
Run the follow and inspect x and y after the #become: and #oneWayBecome:.  
The former is bi-directional, the latter, 1 direction.

x := 'x'.
y := 'y'.
x become: y.

x := 'x'.
y := 'y'.
x oneWayBecome: y.

> What should I do if I want that all what points to anStub points to nil?

anStub oneWayBecome: nil

--
Regards
HweeBoon
MotionObj

"Esteban A. Maringolo" <[hidden email]> wrote in message
news:[hidden email]...
> Hi,
>
>    reading the method comment of #oneWayBecome: it mentions about the
> efficience of the implementation.
>...
> What kind of efficience does it refers?

Time it and see, the difference will soon be evident.

Swapping #become: performs a pointer swap (not exactly, but close enough)
and is therefore virtually instantaneous. #oneWayBecome: scans the entire
object memory, and is thus many orders of magnitude slower. In fact I would
expect it to be too slow for implementing proxies.

I'm not sure I understand the question. #oneWayBecome: replaces all
references to the receiver with references to the argument. #become:
effectively swaps the references. #become: preserves identity, whereas
#oneWayBecome: loses the identity of one object (the receiver). In the case
of #become:, any collections containing the affected objects that are hashed
by identity (e.g. an IdentityDictionary) will remain valid. This is not true
of #oneWayBecome:, which will invalidate any hashed collections holding
references to the "lost" object.

It is, perhaps, easier to understand the behaviour of #become: if you think
of an object as having an identity (or header) and a value (or body).
#become: swaps the bodies over.  #oneWayBecome:, on the other hand, replaces
the identity of one object with another.

>
> What should I do if I want that all what points to anStub points to nil?

You would have to use #oneWayBecome: for that. If you attempt to #become:
anything to nil in Dolphin an error will be raised (no damage will be done).

Regards

Blair

Blair McGlashan escribió:
> "Esteban A. Maringolo" <[hidden email]> wrote
>>   reading the method comment of #oneWayBecome: it mentions about the
>>efficience of the implementation.
>>...
>>What kind of efficience does it refers?

> Time it and see, the difference will soon be evident.
> Swapping #become: performs a pointer swap (not exactly, but close enough)
> and is therefore virtually instantaneous. #oneWayBecome: scans the entire
> object memory, and is thus many orders of magnitude slower. In fact I would
> expect it to be too slow for implementing proxies.

Ok, there is the key. Thanks.

>>I'm using #oneWayBecome: to transform stubs (Subclasses of ProtoObject)
>>into concrete objects, the stubs represents "external objects" which are
>>loaded at demand.

>>But i'm not very sure about the "pointing" of the objects.
>>
>>E.g. objectA (concrete), stub1 (of objectB), stub2 (of objectA), stub3 (of objectA)
>>
>>If stub2 becomes the concrete objectA, so all what where pointing to stub2
>>now points to objectA. If I want to preserve identity and contents and
>>objectA, when stub3 becomes the existing objectA it should do it using
>>#oneWayBecome:, am I right?

> I'm not sure I understand the question.
Perhaps I have to take those english lessons once and forever :-D

 > #oneWayBecome: replaces all references to the receiver with
 > references to the argument.
This is what I want.

 > [SNIP]
> #oneWayBecome: loses the identity of one object (the receiver).

That wouldn't be a problem, indeed i want to loose that object.
Because it will be used only once, once a message has been send to
it, it will transform (become) into another object or to nil*.

*It will lookup in the cache (if is loaded), in the external space
(whatever) and if it doesn't exists in any of those, will become nil
(it really doesn't exists externally)

 > In the case of #become:, any collections containing the affected
 > objects that are hashed by identity (e.g. an IdentityDictionary)
 > will remain valid.
 > This is not true of #oneWayBecome:, which will invalidate any
 > hashed collections holding references to the "lost" object.

Can be this issue handled automatically, or have to be rehashed
explicitly?
Which can be very difficult if the object doesn't know who's holding
it, the case with all the collections e.g.

> It is, perhaps, easier to understand the behaviour of #become: if you think
> of an object as having an identity (or header) and a value (or body).
> #become: swaps the bodies over.  #oneWayBecome:, on the other hand, replaces
> the identity of one object with another.

Yes... I think it in that way, that's why i want to preserve target
identity.

Is possible to make a trick to speed up the proccess of
#oneWayBecome: using a combination of #becomes:'s... or similar

>>What should I do if I want that all what points to anStub points to nil?
> You would have to use #oneWayBecome: for that. If you attempt to #become:
> anything to nil in Dolphin an error will be raised (no damage will be done).

Ok... so my problem now focues on how to speed up #oneWayBecome: or
assume that this is the way it works, and use it as it comes.

Thank you very much.


--
Esteban A. Maringolo
[hidden email]

Hi (hola)

> Ok... so my problem now focues on how to speed up #oneWayBecome: or
assume that this is the way it works, and use it as it comes.

I would suggest you to not use any kind of become for that purpose, if the
problem is to get the realSubject of the proxy you could wrap it with the
same proxy. I mean, add an instance variable in the proxy and keep the
real subject there, forwarding from the proxy. You shouldn't have many
perfomance problem in that way.

Bye (chau)

Diego Coronel

Hola Diego:

"DiegoC" <[hidden email]> wrote

>> Ok... so my problem now focues on how to speed up #oneWayBecome: or
>> assume that this is the way it works, and use it as it comes.

> I would suggest you to not use any kind of become for that purpose, if the
> problem is to get the realSubject of the proxy you could wrap it with the
> same proxy.

Do you say it by particular experience, or just becaus it smells "rare"?

> I mean, add an instance variable in the proxy and keep the
> real subject there, forwarding from the proxy. You shouldn't have many
> perfomance problem in that way.

No, I won't have performance problems, just one additional hop in the
message sequence[*].

One solution I had was having proxies instead of "mutational" stubs, the
proxy solution seemed to be more simple and stable, but the "mutational"
solution is seems more transparent, being those stub disposable, or "use it
once, become the real, and let the GC throw it away". The stability and
performance were the issues on which I had doubts.

[*] Unless message forwarding is handled by the VM or optimized somehow.

Thank you (gracias)

--
Esteban A. Maringolo

>Do you say it by particular experience, or just becaus it smells "rare"?

I don't know the context of your application so I can't answer it, but
every time I can avoid #become: do it. There are many side effects that
you will find using it.

Diego

DiegoC wrote:

> I don't know the context of your application so I can't answer it, but
> every time I can avoid #become: do it. There are many side effects that
> you will find using it.

Such as ?   I've made very extensive use of #become: in one of my things and
experienced no problems at all -- it was very simple and effective.  (You do
have to keep your head fairly straight, though.  Not a good idea to try to
program with #become: if you are under the influence of Strong Drink ;-)

    -- chris

Esteban A. Maringolo wrote:

> That wouldn't be a problem, indeed i want to loose that object.
> Because it will be used only once, once a message has been send to
> it, it will transform (become) into another object or to nil*.
>
> *It will lookup in the cache (if is loaded), in the external space
> (whatever) and if it doesn't exists in any of those, will become nil
> (it really doesn't exists externally)

If you are using proxies, then I don't think that using nil to mean "there was
no data" is a very good design (even if you could implement it).  It means that
client code will suddenly see an object (the proxy) that they legitimately
expect to respond to one protocol (the protocol understood by the "real"
objects) change into a different object that responds to a completely different
protocol.  That would (at least) make the client code very complicated.

I suggest you consider using an explicit "No Data" object -- an object that
"knows" that it represents a gap in the data, but which responds sensibly to
the normal protocol.   E.g. you'd have Customer objects that know their #name
and which answer false to #isBlank, and BlankCustomer objects that answer nil
to #name and true to #isBlank.  And you'd have CustomerProxy objects that would
turn (magically) into a Customer or into a BlankCustomer.

> Is possible to make a trick to speed up the proccess of
> #oneWayBecome: using a combination of #becomes:'s... or similar

I don't believe so.   And if there was, surely Blair would be using the trick
to speed up #oneWayBecome: in the VM already ;-)

I'm not sure if this is an actual /proof/ that you can't implement
#oneWayBecome: with #become: (and some temporary objects too, perhaps), but it
sounds persuasive to me:  Since #become: never decreases the number of object
references in existence, and creating temporary objects can only increase the
number of references, it seems to follow that they can't be used to implement
#oneWayBecome: since that /decreases/ the number of references by one.

    -- chris

"Esteban A. Maringolo" <[hidden email]> wrote in message
news:41e57eae$[hidden email]...
You could use #become: for the newly created objects you load from the
external space - these won't have any existing references, so a swapping
become will be fine as well as very fast. However, when you encounter a
second stub referencing an existing object you can't swap out that second
stub with become, because that would break the references created when the
first stub was swapped. #oneWayBecome: would work, but it is relatively very
slow.

You could change your design so that you can always use #become:.
Essentially you have to avoid creating multiple stubs for the same external
object. This usually involves maintaining tables of both stubs and loaded
objects so that you can make sure you share the same stub when creating a
stub, or that instead of creating a stub you use a loaded object when
already available. These tables are often needed anyway in order to manage
updating external data with changes made to an object while loaded, etc. Of
course it is necessary to think quite hard about the interaction of #become:
with your tables (usually implemented as hashed collections). As Chris says,
approach this design problem when sober :-).

Regards

Blair

Hi Chris,

Chris Uppal escribió:
> Esteban A. Maringolo wrote:
>>That wouldn't be a problem, indeed i want to loose that object.
>>Because it will be used only once, once a message has been send to
>>it, it will transform (become) into another object or to nil*.

> If you are using proxies, then I don't think that using nil to mean "there was
> no data" is a very good design (even if you could implement it).

> It means that
> client code will suddenly see an object (the proxy) that they legitimately
> expect to respond to one protocol (the protocol understood by the "real"
> objects) change into a different object that responds to a completely different
> protocol.  That would (at least) make the client code very complicated.

Well... actually they're not proxies, They're "stubs" (i don't know
if there is a lot of semantic difference).

The system is a OR Persistence framework i'm building for an app,
which maps attributes (i.v.) to columns in direct mappings, or to
other tables, or to 1-to-n, etc.

Let's say you have anAddress, this address has a "location" (a
City). When the broker read the definition for reads the definition
of the object, it knows (by that attribute mapping) which class of
object should go there (in the "location" i.v., say... location).

It creates a stub (anORPStub), which has the class of the (future)
object, hereafter the subject, and the key object to read it (let's
say, it's Id, Code, etc).

Once anORPStub receives a message (which should go to it's subject)
it will lookup in the session object registry (a kind of cache)
using it class and key, if the session doesn't find it in it's cache
it will lookup in the storage (SQL by now), if doesn't exists, it
will answer nil, or the object (new or cached). The stub will become
(oneWay) the object answered.

This has the flexibility of a lazy initialization of everything
which is not a String, Number, Date or any other "simple" not
relational data type in the Table. Which never comes recursive,
because if objectA refers to objectB the flow will be:

1. Read, instance and cache objectA from the DB
2. Create objectB's stub in objectA.
3. Once objectB receives any message, it will instance, and cache,
and create objectA stub.
4. because objectA already is in the smalltalk (cached), objectA
stub will become the real object, and the recursion gets solved.

> I suggest you consider using an explicit "No Data" object -- an object that
> "knows" that it represents a gap in the data, but which responds sensibly to
> the normal protocol.   E.g. you'd have Customer objects that know their #name
> and which answer false to #isBlank, and BlankCustomer objects that answer nil
> to #name and true to #isBlank.  And you'd have CustomerProxy objects that would
> turn (magically) into a Customer or into a BlankCustomer.

Yes... i tend to have a "virtual nothing" in almost everything, an
object that is to my domain as nil is to smalltalk. But as continue
learning, i'm not reinforcing that approach.

>>Is possible to make a trick to speed up the proccess of
>>#oneWayBecome: using a combination of #becomes:'s... or similar

> I don't believe so.   And if there was, surely Blair would be using the trick
> to speed up #oneWayBecome: in the VM already ;-)

Of course, my suggestion was ingenuous, but one never knows... :-)

> I'm not sure if this is an actual /proof/ that you can't implement
> #oneWayBecome: with #become: (and some temporary objects too, perhaps), but it
> sounds persuasive to me:

 > Since #become: never decreases the number of object
> references in existence, and creating temporary objects can only increase the
> number of references, it seems to follow that they can't be used to implement
> #oneWayBecome: since that /decreases/ the number of references by one.

Of course, become maintains the entropy at the same level, not
adding anything, just swapping. oneWayBecome, on the other hand,
will redirect refences.

Thanks in advance.

--
Esteban A. Maringolo
[hidden email]

Blair McGlashan escribió:
> "Esteban A. Maringolo" <[hidden email]> wrote in message
> news:41e57eae$[hidden email]...
>>Blair McGlashan escribió:

Yes... that could be a good solution, because the failures will
reduce over time, being the first objects loaded with #become:
However, oneWayBecome: is slow, but by now, the system won't have
million of objects, as far 500K, being almost everything in memory.
I could benchmark that too.

> You could change your design so that you can always use #become:.
> Essentially you have to avoid creating multiple stubs for the same external
> object. This usually involves maintaining tables of both stubs and loaded
> objects so that you can make sure you share the same stub when creating a
> stub, or that instead of creating a stub you use a loaded object when
> already available.
 > These tables are often needed anyway in order to manage
> updating external data with changes made to an object while loaded, etc. Of
> course it is necessary to think quite hard about the interaction of #become:
> with your tables (usually implemented as hashed collections).

I see... that is a very more "explicit" way of handling stubs, but I
like. I think I will take that approach. The only overhead i'll have
is the stub lookup at "load" time, but perhaps that lookup will be
shorter than the  oneWayBecome once used. One is instantaneous, and
the oneWayBecome: lazy, but I like more your suggestion. Thanks!

 > As Chris says, approach this design problem when sober :-).

Oh! I've started it after drinking some beer. This explains a lot :-D

Yar, Chris, Diego and Blair, thank you all very much, you'll have
notices and/or future issues :-)


--
Esteban A. Maringolo
[hidden email]

Debugging can gets more difficult; workspaces, inspectors and open views
could show you confusing information. I'am not saying to avoid it use,
just to be carefull and consider that in most cases you can solve the same
wrapping your objects inside others and reference those ones. For example
I've seen desings where anInvoice becomes aReceipt, and things like that.
I've found that most times you get better designs without become.
On the other I was impressed by the perfomance of Dolphin's #become:
implementation, and also I admit I've used in a real systems.

Diego Coronel

DiegoC escribió:
> Debugging can gets more difficult; workspaces, inspectors and open views
> could show you confusing information.

It's true, i've had many crashes until it got stable.
Now it's stable. And when I open an inspector, it becomes the real
object and inspects the object or nil.

For example, i was missing the the forward of the first message
(which caused the become), and my objects didn't respond  until the
second send :-D

 > I'am not saying to avoid it use,
> just to be carefull and consider that in most cases you can solve the same
> wrapping your objects inside others and reference those ones.

Yes... indeed I did wrapping/proxying for objects* external to the
smalltalk.

* when i say objects I refer to true objects outside, not to
persisted data (which is the actual case).

 > For example
> I've seen desings where anInvoice becomes aReceipt, and things like that.
> I've found that most times you get better designs without become.

wow, that's ugly, and it's not the case.
Because it doesn't affect the operation of my domain objects and
rules. It's just the object between a living ambiance (the
smalltalk), and the persistence system.

> On the other I was impressed by the perfomance of Dolphin's #become:
> implementation, and also I admit I've used in a real systems.

I've didn't tested it. If I have time I would benchmark it (knowing
how, of course :-) ).

Best regards.

--
Esteban A. Maringolo
[hidden email]

DiegoC wrote:

> Debugging can gets more difficult; workspaces, inspectors and open views
> could show you confusing information.

Agreed.


> I'am not saying to avoid it use,
> just to be carefull and consider that in most cases you can solve the same
> wrapping your objects inside others and reference those ones.

Agreed that it's worth /considering/.  But having considered I think I'd often
reject the idea ;-)  (Wrapping introduces it's own layer of complexity and
inefficiency, and since Smalltalk provides a mechanism "in the box" to handle
such cases gracefully (#become:) my POV is "why not use that ?")


> For example
> I've seen desings where anInvoice becomes aReceipt, and things like that.

Ye Gods!  That is /vile/  Someone should be shot.


> I've found that most times you get better designs without become.
> On the other I was impressed by the perfomance of Dolphin's #become:
> implementation, and also I admit I've used in a real systems.

Going back to my point, above, about Smalltalk having a mechanism for
dynamically changing an object's implementation.  I think of the design choice
(in the Dolphin VM) to use an object table (with a consequent level of
indirection between an object "reference" and the memory representing its body)
as at least partially in order to support a #become: operation that works at
worthwhile speed.  As such it is one of the many examples in Smalltalk's design
where the language/implementation chooses to provide us programmers with
convenience and power even at the cost of a less efficient implementation.
I.e. you are already paying the cost of having an efficient #become: it'd be a
shame to waste it ;-)

    -- chris

Esteban,

> Well... actually they're not proxies, They're "stubs" (i don't know
> if there is a lot of semantic difference).

OK.  I tend to use the word "proxy" for everything, but I think you are right.


> Once anORPStub receives a message (which should go to it's subject)
> it will lookup in the session object registry (a kind of cache)
> using it class and key, if the session doesn't find it in it's cache
> it will lookup in the storage (SQL by now), if doesn't exists, it
> will answer nil, or the object (new or cached). The stub will become
> (oneWay) the object answered.

Reading your reply to Blair, it sounds as if you've decided to change that
design a bit.  I just wanted to add that if you can control the referential
integrity in the DB closely enough, then you could ensure that you never create
a stub for data that will (later) turn out not to exist.  I.e. you would use
nil instead of a stub if there is a NIL reference in the database, otherwise
create a stub which will assume that it can read in valid data later (and will
throw an error if that fails).


> Yes... i tend to have a "virtual nothing" in almost everything, an
> object that is to my domain as nil is to smalltalk. But as continue
> learning, i'm not reinforcing that approach.

Odd that.  I started out not using them much, but find that I'm using them more
and more as time goes on...  Maybe we'll meet somewhere in the middle ;-)


> > > Is possible to make a trick to speed up the proccess of
> > > #oneWayBecome: using a combination of #becomes:'s... or similar
>
> > I don't believe so.   And if there was, surely Blair would be using the
> > trick to speed up #oneWayBecome: in the VM already ;-)
>
> Of course, my suggestion was ingenuous, but one never knows... :-)

I'm sorry.  I misread you as asking /whether/ such a trick existed; I didn't
realise you were saying you had already /found/ one.  What is it please ?
(Unless the "entropy" argument has persuaded you that it won't work).

    -- chris

Hi Chris:

Chris Uppal escribió:

>>Once anORPStub receives a message (which should go to it's subject)
>>it will lookup in the session object registry (a kind of cache)
>>using it class and key, if the session doesn't find it in it's cache
>>it will lookup in the storage (SQL by now), if doesn't exists, it
>>will answer nil, or the object (new or cached). The stub will become
>>(oneWay) the object answered.

> Reading your reply to Blair, it sounds as if you've decided to change that
> design a bit.
 > I just wanted to add that if you can control the referential
> integrity in the DB closely enough, then you could ensure that you
 > never create a stub for data that will (later) turn
 > out not to exist.

I do this, if the reference is nil. I'm only instancing the stub if
the value (the key which is foreign) isn't nil (aDBRow at:
'myReferencedColumn' is nil).

Now i've changed it to ask for the stub, instancing it if neccesary.
I'm having problems, many recursions too deep, GPFaults, something
is going wrong, perhaps I wasn't sober enough.

>>Yes... i tend to have a "virtual nothing" in almost everything, an
>>object that is to my domain as nil is to smalltalk. But as continue
>>learning, i'm not reinforcing that approach.

> Odd that.  I started out not using them much, but find that I'm using them more
> and more as time goes on...  Maybe we'll meet somewhere in the middle ;-)

Or perhaps I'll go reverse.

>>>>Is possible to make a trick to speed up the proccess of
>>>>#oneWayBecome: using a combination of #becomes:'s... or similar

>>>[SNIP]
>>[SNIP]
> I'm sorry.  I misread you as asking /whether/ such a trick existed;
 > I didn't realise you were saying you had already /found/ one.

No no, your intuition was right. I wrote that wrong. Where reads "Is
Possible" should say "It is possible". My english isn't the best :-D

 > What is it please ?

That is ;-)

 > (Unless the "entropy" argument has persuaded you that it won't work).

Too much reading of Stephen Hawking perhaps... :-D


Best regards

--
Esteban A. Maringolo
[hidden email]