Just by curiosity, is there a problem that could be tackled using the StratificationProxy that cant be solved nowadays in Pharo? At least one example of usage would be interesting to learn. Fernando On Wed, Feb 2, 2011 at 9:21 PM, Igor Stasenko <siguctua@gmail.com> wrote:

(@Eliot, don't skip this message there is a regression detected in Cog with this stuff).

I read the paper, which i found once on Stephane's table: Proxies: Design Principles for Robust Object-oriented Intercession APIs [1]

and we discussed it.. and while there is not much interesting stuff for smalltalkers, still a couple of things were said about smalltalk that was not quite true :)

The main point was: in smalltalk you can't do proper stratification. Yes, we can.

Some background: ---- 4.3 Stratification Bracha and Ungar [2] introduce the principle of stratifica- tion for mirror-based architectures. The principle states that meta-level facilities must be separated from base-level func- tionality. Bracha and Ungar focus mostly on stratification in the context of introspection and self-modification. In this pa- per we focus on the application of this principle to interces- sion. Mirrors are further discussed in Section 7.2. The distinction between a proxy and its handler object enforces stratification of the traps. Traps are not defined as part of the interface of the proxy object, but as part of the interface of the handler. The handler is a regular object. It may inherit from other objects, and its inheritance chain is completely independent from that of the proxy it handles. A single handler may handle multiple proxies. The handler can be a proxy itself (we will illustrate a use case of this in Section 4.5). Accessing aProxy.has explicitly on a proxy will not trig- ger the proxy’s corresponding has trap. Instead, the access will be reified like any other as handler.get(aProxy,‘has’). Like- wise, aProxy.get is reified as handler.get(aProxy,‘get’). Traps can only be invoked explicitly on a proxy’s handler, not on the proxy itself. This enforces stratification (the meta-level traps should not interfere with base-level method names). Thus, proxies continue to work correctly if an application (by ac- cident or by design) uses the names get, set, etc. The principle of stratification when applied to proxies can be summarized as follows. Stratification: a proxy’s traps should be stratified by defining them on a separate handler object. ----

Usually, when implementing a proxies in smalltalk, we are creating a subclass of Object, or ProtoObject and then by using DNU pattern implementing a handler for messages. It works most of the ways, except that for #doesNotUnderstand: and rest of method implemented in Object/ProtoObject you cannot make difference if this message sent by VM (because of lookup failure) or it were sent directly to proxy object, like:

proxy doesNotUnderstand: foo

So, such kind of proxies are not having proper stratification.

But it does not means that we could not have a proper 'stratification' in smalltalk..

The proxy implementation, which i presented more than a year ago doing it without much problems.

In [2] there is "beautified" "stratified" proxy implementation + some examples which showing how to implement various kinds of proxies based on it.

So, to the summary, which can be found at the end of that paper, we can to add some corrections:

API:

Smalltalk cannotInterpret:

Values that can be virtualized  - it was like that before JS were born Stratification  -  yes, sure, why not Temporary Intercession - yes, sure, why not Meta-level shifting  - yes, sure, why not Meta-level funnelling - yes, sure, why not Selective interception - No, since all interaction is via messages, and all messages are trapped Fundamental vs. Derived Traps - we don't need that BS Handler Encapsulation - piece of cake Uniform intercession  - it was like that before JS were born

:)

There is only one thing, which not OK with it:  - Cog having a regression comparing to Squeak VM. Its not handling #cannotInterpret: message correctly.

[1] research.google.com/pubs/archive/36574.pdf [2] http://code.google.com/p/pharo/issues/detail?id=3648

-- Best regards, Igor Stasenko AKA sig.

Hi Igor, On Wed, Feb 2, 2011 at 1:21 PM, Igor Stasenko <siguctua@gmail.com> wrote:

(@Eliot, don't skip this message there is a regression detected in Cog with this stuff).

I read the paper, which i found once on Stephane's table: Proxies: Design Principles for Robust Object-oriented Intercession APIs [1]

and we discussed it.. and while there is not much interesting stuff for smalltalkers, still a couple of things were said about smalltalk that was not quite true :)

The main point was: in smalltalk you can't do proper stratification. Yes, we can.

Some background: ---- 4.3 Stratification Bracha and Ungar [2] introduce the principle of stratifica- tion for mirror-based architectures. The principle states that meta-level facilities must be separated from base-level func- tionality. Bracha and Ungar focus mostly on stratification in the context of introspection and self-modification. In this pa- per we focus on the application of this principle to interces- sion. Mirrors are further discussed in Section 7.2. The distinction between a proxy and its handler object enforces stratification of the traps. Traps are not defined as part of the interface of the proxy object, but as part of the interface of the handler. The handler is a regular object. It may inherit from other objects, and its inheritance chain is completely independent from that of the proxy it handles. A single handler may handle multiple proxies. The handler can be a proxy itself (we will illustrate a use case of this in Section 4.5). Accessing aProxy.has explicitly on a proxy will not trig- ger the proxy’s corresponding has trap. Instead, the access will be reified like any other as handler.get(aProxy,‘has’). Like- wise, aProxy.get is reified as handler.get(aProxy,‘get’). Traps can only be invoked explicitly on a proxy’s handler, not on the proxy itself. This enforces stratification (the meta-level traps should not interfere with base-level method names). Thus, proxies continue to work correctly if an application (by ac- cident or by design) uses the names get, set, etc. The principle of stratification when applied to proxies can be summarized as follows. Stratification: a proxy’s traps should be stratified by defining them on a separate handler object. ----

Usually, when implementing a proxies in smalltalk, we are creating a subclass of Object, or ProtoObject and then by using DNU pattern implementing a handler for messages. It works most of the ways, except that for #doesNotUnderstand: and rest of method implemented in Object/ProtoObject you cannot make difference if this message sent by VM (because of lookup failure) or it were sent directly to proxy object, like:

proxy doesNotUnderstand: foo

So, such kind of proxies are not having proper stratification.

But it does not means that we could not have a proper 'stratification' in smalltalk..

The proxy implementation, which i presented more than a year ago doing it without much problems.

In [2] there is "beautified" "stratified" proxy implementation + some examples which showing how to implement various kinds of proxies based on it.

So, to the summary, which can be found at the end of that paper, we can to add some corrections:

API:

Smalltalk cannotInterpret:

Values that can be virtualized - it was like that before JS were born Stratification - yes, sure, why not Temporary Intercession - yes, sure, why not Meta-level shifting - yes, sure, why not Meta-level funnelling - yes, sure, why not Selective interception - No, since all interaction is via messages, and all messages are trapped Fundamental vs. Derived Traps - we don't need that BS Handler Encapsulation - piece of cake Uniform intercession - it was like that before JS were born

:)

There is only one thing, which not OK with it: - Cog having a regression comparing to Squeak VM. Its not handling #cannotInterpret: message correctly.

Yes, I didn't implement the cannotInterpret: hook for Cog fully. I'll take a look at this soon. cheers, Eliot

[1] research.google.com/pubs/archive/36574.pdf [2] http://code.google.com/p/pharo/issues/detail?id=3648

-- Best regards, Igor Stasenko AKA sig.