From: David Simmons Date: 2001-08-16T11:36:29+09:00 Subject: [ruby-talk:19856] Re: Why not?: Assigning to self "Yukihiro Matsumoto" wrote in message news:997845654.140902.17914.nullmailer@ev.netlab.jp... > Hi, > > In message "[ruby-talk:19711] Re: Why not?: Assigning to self" > on 01/08/15, Ned Konz 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.