Administrator
|
From "Design Patterns" pg. 215:
You can make[8] generic proxies in Smalltalk by defining classes whose superclass is nil and defining the doesNotUnderstand: method to handle messages. [8] Almost all classes ultimately have Object as their superclass. Hence this is the same as saying "defining a class that doesn't have Object as its superclass." but in Pharo: nil subclass: #MyProxy instanceVariableNames: '' classVariableNames: '' category: '' -> MessageNotUnderstood: receiver of "subclass:instanceVariableNames:classVariableNames:category:" is nil
Cheers,
Sean |
Sean,
I am not an expert in Pharo, but I think you should try subclassing ProtoObject... Joachim Am 31.03.2015 18:51 schrieb "Sean P. DeNigris" <[hidden email]>: > > >From "Design Patterns" pg. 215: > > You can make[8] generic proxies in Smalltalk by defining classes whose > superclass is nil and defining the doesNotUnderstand: method to handle > messages. > > [8] Almost all classes ultimately have Object as their superclass. Hence > this is the same as saying "defining a class that doesn't have Object as its > superclass." > > but in Pharo: > nil subclass: #MyProxy > instanceVariableNames: '' > classVariableNames: '' > category: '' > -> MessageNotUnderstood: receiver of > "subclass:instanceVariableNames:classVariableNames:category:" is nil > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Proxies-Subclassing-nil-tp4816443.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > |
In reply to this post by Sean P. DeNigris
Hi if you want to build proxy look at Ghost library from Mariano Martinez I not know right repository. Maybe this:http://smalltalkhub.com/#!/~CAR/Ghost/ or http://ss3.gemstone.com/ss/Ghost 2015-03-31 19:51 GMT+03:00 Sean P. DeNigris <[hidden email]>: From "Design Patterns" pg. 215: |
Administrator
|
In reply to this post by jtuchel
I wonder if it was correct that subclassing nil used to be allowed and the proper way to create a proxy, and if so why it was changed...
Cheers,
Sean |
Administrator
|
In reply to this post by Denis Kudriashov
Thanks, Denis! I'll check it out. I'm not sure which repo either. Mariano's commits are all in both places, but there seems to be some parallel development after that...
Cheers,
Sean |
Administrator
|
I loaded the Pharo 3.0 stable version of the Metacello config in MetaRepoForPharo30 (1.2). All tests pass, so I updated the config for 4.0 and copied it to the meta repo for 40
Cheers,
Sean |
In reply to this post by Sean P. DeNigris
Hey Sean, Now to create a proxy you need to subclass ProtoObject and not nil. This was changed years ago to avoid some issues. An example of issue that existed: when you subclass nil, as #doesNotUnderstand: is not implemented by default on your proxy, any proxy created receiving a message would crash the VM if you had not overridded #doesNotUnderstand:. Another example is that when you iterate over memory using #nextObject, if the proxy does not answer it you can end with severe VM crashes. In these examples I am talking about the expected VM behavior and not about bugs. So basically the purpose of ProtoObject was to limit the number of VM crashes when playing with proxies / ProtoObjects, instead having a default behavior for several messages such as #doesNotUnderstand: or nextObject. Note that the IDE support for ProtoObject is limited as ProtoObject API is very restricted so it does not have methods such as #inspect, ... That's also on purpose because Proxies may not implement introspection methods. 2015-03-31 14:53 GMT-07:00 Sean P. DeNigris <[hidden email]>: Denis Kudriashov wrote |
On Tue, Mar 31, 2015 at 8:05 PM, Clément Bera <[hidden email]> wrote:
Yes, subclassing from nil was never a good idea.
Marea (kind of extended Ghost proxies) proxies deal with object listing. If you load Marea code, see class side of #MARAbstractProxy (#allInstances, #allInstancesDo: etc).
Yes. Ghost proxies provided debugger facilities (printing, inspecting, debugging, exploring, etc) which could be dynamically either enabled or disabled. If enabled, you could debug proxies without intercepting the "debugging" methods.
|
In reply to this post by Denis Kudriashov
Mariano spent a couple of years on it so...
Le 31/3/15 21:37, Denis Kudriashov a
écrit :
|
but it has not diverged too much from the old one yet. #Luc 2015-04-01 8:29 GMT+02:00 stepharo <[hidden email]>:
|
On Wed, Apr 1, 2015 at 4:29 AM, Luc Fabresse <[hidden email]> wrote:
Luc...something that would be super super cool is to take the proxies I implemented for Marea and adapt them as custom Ghost proxies. Because the idea of Ghost was mostly the design, not the code itself. The code was very very little. So in Marea proxies you can see how I: 1) Created a few different proxies for different purposes. For example, I created special proxies for classes and metaclasses. And each of them implements custom messages to avoid unnecessary interception (for example, MARMetaclassProxy implements #isMeta answering true. Both, proxy for Class and Metaclass implement: isKindOf: aClass ^ (aClass == Class) ifTrue: [ true ] ifFalse: [ super isKindOf: aClass ] "would be intercepted" and so on.... So basically....you are able to implement custom proxies and implement custom messages so that you avoid intercepting them. 2) In Marea, I have multiple proxies that store the information differently. So for example, Marea proxies needed a graph id and a "position" (an integer). If both were small enough, I was doing a bitShift and storing them in a super compact proxy class that would have only one small integer. So....what I want to say is that while ghost code is OK, the most interesting usage and development of those proxies is in Marea, in the category 'Marea-Proxies'.
|
Free forum by Nabble | Edit this page |