Smalltalk › Pharo › Pharo Smalltalk Developers

Our response to JS proxy API + Cog regression

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Igor Stasenko

Our response to JS proxy API + Cog regression

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

Fernando olivero-2

Re: Our response to JS proxy API + Cog regression

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 <[hidden email]> 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.
>
>

Igor Stasenko

Re: Our response to JS proxy API + Cog regression

On 2 February 2011 23:25, Fernando Olivero <[hidden email]> wrote:
> Just by curiosity, is there a problem that could be tackled using the
> StratificationProxy that cant be solved nowadays in Pharo?
>
Any problem where you usually using proxies.
These proxies just make sure that nothing can go past handler unnoticed.

> At least one example of usage would be interesting to learn.
>

Well, i had need such proxies once to provide a syntactic sugar for
lambda-message-sends.

lambdas could be built directly using message sends, i.e.:

lambda foo: bar.

are turned into instance of Lambda( receiver=lambda , selector = #foo:
, arguments = #(bar))

now everything works fine, if lambda does not implements #foo:
message, and therefore by sending it,
it intercepts this message in own DNU handler and creates a new lambda
which encapsulating a message send and its argument(s).

But when message is implemented by Lambda itself, things become less
simple and more tedious, because i need to initialize Lambda fields
manually, i.e. instead of writing:

newLambda := lambda at: 1.

i need to write:

newLambda := Lambda receiver: lambda selector: #at: arguments: #(1).

but using the proxy i can write it like following:

newLambda := lambda pure at: 1.

where #pure means that message send which will follow given message is
guaranteed to be captured as LMS instead of
being invoked normally.

> Fernando
>
>

--
Best regards,
Igor Stasenko AKA sig.

Marcus Denker-4

Re: Our response to JS proxy API + Cog regression

In reply to this post by Igor Stasenko

On Feb 2, 2011, at 10:21 PM, Igor Stasenko wrote:
>
> 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 :)
>
Our other answer (published already last year...) is of course this paper:

http://rmod.lille.inria.fr/web/pier/publications/bib?&query=Arna10a&display=abstract&_n&15

Jean-Baptiste Arnaud, Marcus Denker, Stéphane Ducasse, Damien Pollet, Alexandre Bergel, and Mathieu Suen. Read-Only Execution for Dynamic Languages.

Abstract
Supporting read-only and side effect free execution has been the focus of a large body of work in the area of statically typed programming languages. Read-onlyness in dynamically typed languages is difficult to achieve because of the absence of a type checking phase and the support of an open-world assumption in which code can be constantly added and modified. To address this issue, we propose Dynamic Read-Only references (DRO) that provide a view on an object where this object and its object graph are protected from modification. The read- only view dynamically propagates to aggregated objects, without changing the object graph itself; it acts as a read-only view of complex data structures, without making them read-only globally. We implement dynamic read-only references by using smart object proxies that lazily propagate the read-only view, following the object graph and driven by control flow and applied them to realize side-effect free assertions.

Marcus

--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Eliot Miranda-2

Re: Our response to JS proxy API + Cog regression

In reply to this post by Igor Stasenko

Hi Igor,

On Wed, Feb 2, 2011 at 1:21 PM, Igor Stasenko <[hidden email]> 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.

Stéphane Ducasse

Re: Our response to JS proxy API + Cog regression

Thanks because this is a really really really good hook.

Stef

>
> 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.
>