[Pharo-project] Our response to JS proxy API + Cog regression

Fernando Olivero fernando.olivero at usi.ch
Wed Feb 2 23:25:40 CET 2011

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.


On Wed, Feb 2, 2011 at 9:21 PM, Igor Stasenko <siguctua at 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.

More information about the Pharo-project mailing list