[squeak-dev] The Trunk: Morphic-cmm.1408.mcz

Marcel Taeumel marcel.taeumel at hpi.de
Fri Apr 6 09:19:29 UTC 2018


Like this, but it would mean to replace all "ActiveWorld" with "ActiveWorld value" calls:


At the moment, we have #becomeActive:during: in HandMorph, MorphicEvent, and PasteUpMorph for this.

Best,
Marcel

Am 06.04.2018 11:14:29 schrieb H. Hirzel <hannes.hirzel at gmail.com>:
On 4/6/18, H. Hirzel wrote:
> Marcel,
>
> is it possible to elaborate what is meant with 'Dynamic variable'?
>
> A good place to do so here
>
> http://wiki.squeak.org/squeak/6481

I mean which type of DynamicVariable do you think of (as mentioned on
the draft notes on page 6481)

> :-)
>
> --Hannes
>
> On 4/6/18, Marcel Taeumel wrote:
>> -1 for Project class >> #currentWorld
>>
>> The interface #currentWorld, #currentHand, and #currentEvent is already
>> there in Object to provide messaging for the dynamically-scoped variables
>> ActiveWorld, ActiveHand, and ActiveEvent.
>>
>> What about making ActiveWorld, ActiveHand, and ActiveEvent *actually* a
>> DynamicVariable? :-)
>>
>> Best,
>> Marcel
>> Am 06.04.2018 06:44:49 schrieb tim Rowledge :
>>
>> Now me personally, I don't like a proliferation of globals. Nor do I like
>> a
>> long chain of structure/api asuming messages.
>>
>> I posit that instead of 'World' we would be less confused and more
>> elegant
>> with'Project currentWorld', where Project is our friendly class and
>> #currentWorld is a method that determines the current Project instance
>> and
>> sends it a message to determine what the current world-equivalent is. We
>> may
>> have kinds of project where the world-equivalent depends upon some other
>> factor, for example.
>>
>> My admittedly extreme view would be that we should never have chained
>> messages and instead do actual delegation from the beginning. Instead of
>> Project current world morphs allSatisfy:[:mrph| mrph
>> veryMorphSpecificThing
>> comparedTo: otherThing extremelyThingRelatedAttribute
>> internalStructureAssumingMessage]
>> I'd really prefer
>> Project widgetsThatMatchOtherThingStatus
>> And yes, even there we are making assumptions about the internals of
>> Project
>> stuff. And I understand that it would likely be near-impossible to go
>> that
>> far and stay sane. But who cares about being sane, eh? Have you seen my
>> water powered over-unity snake?
>>
>> My point - and I do have one - is that every message send is a place to
>> make
>> a useful discrimination about what an object should do. Using messages
>> and
>> accompanying methods that are little more than C struct field name
>> analogues
>> is throwing away that valuable opportunity a.k.a simple accessors are
>> almost
>> always A Bad Thing. I mean, you have heard of encapsulation, right? and
>> abstraction?
>>
>> I now return you to your regularly scheduled diet of whatever. On toast.
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Strange OpCodes: CRN: Compare to Random Number
>>
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180406/4904f3e6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 120247 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180406/4904f3e6/attachment-0001.png>


More information about the Squeak-dev mailing list