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

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Feb 15 15:56:00 UTC 2020


> Not sendTo: instead of sentTo:? ;-)

This was the first mention of #sentTo: in this thread :)

> And I suppose it is fine to ask the decorator programmer to implement an #undecorated method to return the inner object.

Sounds like a mirror problem again? Perfect decorators can be nested with arbitrary depth. What should be the return value of (EasterDecorator on: (ChristmasDecorator on: Object new)) undecorated?
________________________________
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 16:14:54
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [Bug & design issue] Messages understood or not understood by ProtoObject

Not sendTo: instead of sentTo:? ;-)

Agreed that solves it. And I suppose it is fine to ask the decorator
programmer to implement an #undecorated method to return the inner
object. If it makes sense for the particular decorator.


Am Sa., 15. Feb. 2020 um 15:59 Uhr schrieb Thiede, Christoph
<Christoph.Thiede at student.hpi.uni-potsdam.de>:


>
> > 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]
>
> :-)
>
> ________________________________
> 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>:
>>
>> Hi Jakob,
>>
>> On Fri, Feb 14, 2020 at 1:14 PM Jakob Reschke <forums.jakob at resfarm.de> wrote:
>>>
>>> Am Fr., 14. Feb. 2020 um 19:42 Uhr schrieb Eliot Miranda <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> 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/20200215/83501bfd/attachment.html>


More information about the Squeak-dev mailing list