Posted by Chris Uppal-3 on Jan 14, 2005; 10:13am
URL: https://forum.world.st/become-and-oneWayBecome-tp3372645p3372686.html

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