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

Eliot Miranda eliot.miranda at gmail.com
Tue Feb 8 03:24:26 CET 2011

Hi Igor,

On Wed, Feb 2, 2011 at 1: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.

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


> [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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110207/f6526b6a/attachment.htm>

More information about the Pharo-project mailing list