[Cuis-dev] unnecessary punctuation

Ezequiel Birman ebirman77 at gmail.com
Thu Jun 13 12:37:48 PDT 2024


>
> Wouldn't the same concern exist for blocks?

It is *expected* of blocks to understand *#value*. There is no concern; if
you redefine *BlockClosure >> value*, the image will crash.

Blocks are an effective way to delay evaluation, which is exactly what we
need if we are to express conditionals by way of message passing. This
wasn't the case before Smalltalk-80
<https://smalltalkzoo.thechm.org/papers/EvolutionOfSmalltalk.pdf>. (See
sections 7.3 and 7.4).

A quinta, 13/06/2024, 14:15, Mark Volkmann via Cuis-dev <
cuis-dev at lists.cuis.st> escreveu:

>
>
> On Thu, Jun 13, 2024 at 12:56 AM Vanessa Freudenberg via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>>
>>> Doesn't it seem like the compiler could also be optimized to recognize
>>> when the values passed are literal values and then perform the same
>>> optimization it does for blocks? I understand it doesn't do that currently
>>> and so it is more efficient to pass blocks.
>>>
>>
>> How would the compiler know if those “literal” objects understand #value?
>> And how could it be sure that #value returns the same object, unchanged?
>>
>
> I want to understand this concern. Is it that some code could override the
> value method for strings, numbers, or booleans to differ from what the
> Object class provides (which is to return the same object unchanged)?
> Wouldn't the same concern exist for blocks?
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240613/2cd3c996/attachment.htm>


More information about the Cuis-dev mailing list