[squeak-dev] [Bug & design issue] Messages understood or not understood by ProtoObject

Marcel Taeumel marcel.taeumel at hpi.de
Sun Feb 16 10:41:02 UTC 2020


Hi Eliot.

> P.S. I may have the selector wrong, but there is a mirror identical.  Whatever the selector is, I meant that.

It is Context >> #object:eqeq:.

Best,
Marcel
Am 16.02.2020 02:59:55 schrieb Eliot Miranda <eliot.miranda at gmail.com>:

On Feb 15, 2020, at 6:59 AM, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:



> Example:
> 
>    anObject := (MyDecorator on: anotherObject)
>       doSomething;
>       yourself.
> 
> I would like that anObject is the decorator and not anotherObject at the end.

Marcel told me the following tip for this scenario, which sounds quite interesting to me:

doesNotUnderstand: aMessage
| result |

result := aMessage sendTo: target.
^ target == result
ifTrue: [self]
ifFalse: [result]

+1.  Everyone writing proxies should be aware of this.  BUT!! !Ot should be written as

^ (thisContext object: target identical: result)
       ifTrue: [self]
       ifFalse: [result]

to avoid sending a message if #== is a true message send (which is what we’re intending to arrange).

P.S. I may have the selector wrong, but there is a mirror identical.  Whatever the selector is, I meant that.

:-)
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob at resfarm.de>
Gesendet: Samstag, 15. Februar 2020 09:28:58
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [Bug & design issue] Messages understood or not understood by ProtoObject
 
Thanks Eliot, I understood that for the inspector use case, but my thought about #yourself was rather the following:

If I pass the decorator around and some domain code (not in Inspector or similar) uses the decorator in a cascade with yourself at the end, I do not want the result to be the undecorated object.

Example:

    anObject := (MyDecorator on: anotherObject)
       doSomething;
       yourself.

I would like that anObject is the decorator and not anotherObject at the end.

Am Fr., 14. Feb. 2020 um 22:39 Uhr schrieb Eliot Miranda <eliot.miranda at gmail.com [mailto:eliot.miranda at gmail.com]>:

Hi Jakob,

On Fri, Feb 14, 2020 at 1:14 PM Jakob Reschke <forums.jakob at resfarm.de [mailto:forums.jakob at resfarm.de]> wrote:

Am Fr., 14. Feb. 2020 um 19:42 Uhr schrieb Eliot Miranda <eliot.miranda at gmail.com [mailto:eliot.miranda at gmail.com]>:

Hi Christoph,

On Feb 14, 2020, at 9:51 AM, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de [mailto:Christoph.Thiede at student.hpi.uni-potsdam.de]> wrote:

> There is a good solution to this.  Low-level Inspectors *should not* use instVarAt: et al.  Instead they should access object intervals via “the mirror protocol”, see the methods in Context, #object:instVarAt:[put:] #object:at:[put:] #objectClass:

I like and do agree to your vision for tidying up ProtoObject!
Maybe we could also consider some "MetaDecorator" that inherits from ProtoObject and implements #class, #instVarAt: etc. for arbitrary targets? This might simplify the access to the mirror protocol, and it would be a bit more object-oriented:

(MetaDecorator on: aMorph) class "--> Morph"
(MetaDecorator on: aProxy) class "--> Proxy"

(MetaDecorator on: aProxy) instVarsInclude: 'target' "--> true"


Sounds good.


If inspectors et al would use this, my decorators might not have to carry the following collection of methods/copies:

asExplorerString basicInspect basicSize class instVarAt: instVarAt:put: perform: perform:withArguments: primitiveFailed printString printStringLimitedTo: respondsTo: xxxClass


If DataStream et al did, add the following:
readDataFrom:size: storeDataOn:


I'm not sure how to generally handle #yourself. I have this in my decorators as well because I don't want to undecorate when the decorator receives it.


typically use of the mirror protocol, at its most basic, looks like


    thisContext object: foo instVarAt: index

so #yourself is handled by ending the cascade early, and answering the object (foo in the above).  Yes that's a tedious refactor, but straightforward, no?  
--

_,,,^..^,,,_

best, Eliot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200216/5b544c42/attachment.html>


More information about the Squeak-dev mailing list