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

Igor Stasenko siguctua at gmail.com
Wed Feb 2 22:21:10 CET 2011


(@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