I'm doing research in Smalltalk reflection, and I was wondering if it was possible to extend an individual object like that would be possible for instance in Ruby. With this I mean a selector that only particular objects respond to.
Here is some Ruby code that states what I mean. For clarification: in Ruby this open a virtual class for this object, and extends it with a new definition. The vital part here is that nothing changes to the class definition!
o = Object.new
o.instance_eval {def foo;puts "foo";end}
o.foo #=> "foo"
#however this will fail:
m = Object.new
m.foo #=> NoMethod error
More specifically my question is whether this is possible in standard Squeak/Pharo or other smalltalk implementations, without adding substantial structures or code to allow this. So with other words with regular reflective features that exist in Smalltalk.
As an example, it is possible to add methods, remove methods, compile new code into a class, change instance variables and just about anything, but I haven't found a way to extend a single object.
Test addInstVarNamed: #var.
Test compile: 'var ^var'.
t:= Test new.
Test instVarNames.
t instVarNamed: #var put: 666.
t var. #=> 666
If the answer is no, then explain why. I'm not looking for solving this problem but rather understanding why it isn't in smalltalk.
In Smalltalk there is no built in way of doing instance-specific behavior in that way. Smalltalk adheres to the principle that each object belongs to a class and its behavior and state shape depends on the class. That is why you can easily change the class (add inst vars, compile new methods, etc), but that means changing the behavior to all of its instances. There are, however, different approaches (according to the Smalltalk flavor) for achieving instance-specific behavior, such as Lightweight Classes, where the idea is to create a special (lightweight) class for a particular instance and replace the original class with the custom one. As a result you have a special class for each "special" instance. AFAIK in Digitalk St the dispatching mechanism is a bit more flexible and allows to easily implement instance-based behavior (see 4th link). I'll leave here some links that you may find useful:
- Reflective Facilities in Smalltalk-80
- Class Warfare: Classes vs. Prototypes
- Smalltalk Daily 6/4/09: Instance Specific Behavior
- Instance-Specific Behavior for the Working Smalltalker
- Evaluating message passing control techniques in Smalltalk
HTH
Edit: the link posted by Hernan ("Debugging Objects" by Hinkle, Jones & Johnson) is the one to which I was referring and that couldn't find.
Having instance specific behavior in Smalltalk basically involves changing a pointer class and a primitive call. The "Debugging Objects" article by Bob Hinkle, Vicki Jones, and Ralph E. Johnson, published in The Smalltalk Report, Volume 2#9, July-August 1993, contains all the explanations.
I have ported the original Lightweight classes code from the version released in 1995 by Bob Hinkle for VisualWorks 2.0. The VisualWorks source includes code divided in three packages named "ParameterizedCompiler", "Breakpoint" and "Lightweight". The reason of this division was generated by the desire of having separate and re-usable functionality. All of them have separate articles in OOP journals.
My Squeak/Pharo port contains an "Instances Browser", based on the OmniBrowser (and more documentation here) framework, which lets you browse and modify the instances adding the Lightweight behavior through the classic Smalltalk Browser UI. It would work in latest Squeak 4.x versions with little or no effort. Unfortunately the infrastructure of Pharo changed substantially from versions <= 1.2, therefore it may need some work to work it latest versions.
In VisualWorks, due to the deep changes in the VisualWorks GUI from 2.0 to 7.3, most of the tools to manage the lightweight classes were not included. If someone is interested, I can upload the parcel for VW 7.3
A basic script to test the lightweight classes features is:
| aDate |
aDate := Date today.
aDate becomeLightweight.
aDate dispatchingClass
compile: 'day ^42'
notifying: nil
ifFail: [self error].
aDate day inspect
Squeak Etoys heavily makes use of object-specific behavior and state. This is implemented as "uniclasses". When you create a script for an Etoys object (instance of Player class), then the object's class will be changed to a "uniclass", that is, a unique subclass of Player, which can have its own methods (corresponding to Etoys scripts) and instance variables (corresponding to Etoys user variables).
Other Squeak-based projects use "anonymous" uniclasses, which are not listed as subclass in its superclass. That means they are pretty much invisible as they do not show up in a System Browser, for example (whereas Etoys-style uniclasses do show up in the browser).
A colleage has been working a new reflective API for Pharo Smalltalk that is called Bifrost. you can check the page of the Bifrost project.
His approach pushes instance-specific adapations at its core. Everything happens by binding metaobjects to regular objects in order to adapt them. Lower-level metaobjects can be composed into higher-level, coarse-grained, metaobject that define sensible adaptations, e.g. a profiling metaobject that will measure the time each invocation on the target object takes.
As @ewernli points out Bifrost basically makes Smalltalk an object-centric reflection system. All reflective changes are targeted first at objects instead of having an hybrid mechanism with classes. You can still do all the traditional class reflection but on top of object-centric reflection. What I think that is relevant of this new approach is a number of applications that we found that improves how we developed and perceived a live system:
Object-centric debugging completely changes the way we debug by concentrating on objects and allowing the developer to remain interacting with live objects rather than having to insert conditional breakpoints at source code level.
Talents are composable dynamic units of reuse, like traits but for objects. There are many more applications.
In Ruby, as far as I know, a method dictionary attaches to an object.
In Smalltalk, the method dictionary is bound to a Class object so, in a vanilla Smalltalk image, you can't write eigenclass-like things.
Having said that, there are a few prototype libraries: this question's answers mention quite a few.
来源：https://stackoverflow.com/questions/14196417/is-it-possible-to-extend-an-individual-object-in-smalltalk