[ruby-talk:19856] Re: Why not?: Assigning to self

"Yukihiro Matsumoto" <[e-mail]> wrote in message
news:[e-mail]...
> Hi,
>
> In message "[ruby-talk:19711] Re: Why not?: Assigning to self"
>     on 01/08/15, Ned Konz <[e-mail]> writes:
>
> |My discussion of archives was in a different context: that of changing
> |classes of objects. I see lots of problems with doing this in Ruby, which
is
> |why I have been pushing for become(), which would be a cleaner way to do
this
> |in Ruby (or in Smalltalk).
>
> I've once read the pater titled "become considered harmful", but I
> can't find it now.  Anyone know the pointer?  OOPSLA?

Recent posts [last three weeks] on comp.lang.smalltalk have been discussing
some issues surrounding swizzling operations like #become: and its family of
variants for use for implementing object-relational services and similar
proxy/delegate patterns.

generic
-------
    become:

VisualWorks
-----------
    oneWayBecome:

QKS Smalltalk
-------------
    basicBecome:
    basicExchangeIdentityWith:

It is generally considered to be a meta-object operation used specifically
to support things like proxy/delegate functionality. The other [older]
primary (and potentially dangerous use) is to break up object clusters to
assist gc-operations. In some modern Smalltalks where attention has been
given to avoiding persistent object references [better designed threading,
dependency and notification architectures, or modularization to eliminate
the need for snapshot images] this latter usage is effectively not
necessary.
---

The performance of the various messages varies by dialect [i.e., depends on
the gc architecture].

The "dangers" should be pretty apparent. The mechanism is very low level and
directly violates the principles of encapsulation. It is quite easy to
corrupt critical execution/data structures (even with conservative
protection such as in QKS Smalltalk's #become: implementation). It is also a
distinctly innefficient approach to delegation and proxy services.
---

I can speak authoritatively for SmallScript (QKS Smalltalk) since I wrote
it.

In summary, providing direct support for "managed" object services
eliminates the delegation/proxy rationale for using #become:.

In QKS Smalltalk the #become: operation is very fast and is "protected"
against making changes to literals and objects like classes and methods. The
#basicBecome: operations do not offer such validation/protection except for
some very critical elements. Both the #become: and #basicBecome: replace all
slot references to the receiver with the given argument [including
class/behavior info in the header]. As such, the operation requires sweeping
some or all the object space(s) much like a mark&sweep GC phase would [there
are various optimizations that can be intelligently applied to improve
performance based on incorporating knowledge of predominant object types and
inter-generational references (remembered sets)].

In QKS Smalltalk the #basicExchangeIdentityWith: operation takes a few
machine cycles and swaps out information in the object headers. It is
extremely fast, and is, in general, the more useful of the two operations. A
similar/related method is #basicBehavior: (and related methods) which allows
changing the behavior (incl class) of an object. The object will be
restructured as needed to preserve class structure invariant requirements.
This operation is very fast, the VM architecture was designed to ensure this
would be safe, and it is generally a very useful operation for many purposes
including building of lexer/parsers and pickling/linking systems.

In QKS Smalltalk (and SmallScript) the #become: operation is not used/needed
for delegate/proxy operations. The object model provides direct support for
a variety of delegation services which include a general mechanism known as
"managed" objects. An object which is being "managed" can request some or
all of its messages and read/write operations to be delegated/managed by
some other object. This feature can be turned on/off at will on a per/object
basis and takes a few machine instructions. It may, or may not, trigger
rejitting of affected compiled code [depending on VM policy settings].

--
-- Dave S. [ http://smallscript.net ] Agents Object System [AOS]
   Smalltalk for the AOS Platform and The Microsoft.NET Framework

>
> matz.