[Cuis-dev] unnecessary punctuation

[Vanessa Freudenberg]

On Wed, Jun 12, 2024 at 16:32 Mark Volkmann <r.mark.volkmann at gmail.com>
wrote:

>
>
> On Wed, Jun 12, 2024 at 6:04 PM Vanessa Freudenberg via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> On Wed, Jun 12, 2024 at 15:32 Jaromir Matas <mail at jaromir.net> wrote:
>>
>>>
>>> So if I understand correctly the #ifTrue:ifFalse message gets inlined
>>> only when used with block arguments, and it gets really sent when used
>>> without blocks; which means not only there's one more send but also that
>>> **both** 'Yes' and 'No' expressions get evaluated before sending #ifTrue:ifFalse
>>> (hence twice as slow?).
>>>
>>
>> In this case evaluating both arguments is pretty cheap because they’re
>> simple string constants.
>>
>> The slowdown comes mainly from actually having to do the sends of
>> “ifTrue:ifFalse:” and “value”.
>>
>
> 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?

It can’t. And even if it checked at compile time, the behavior could change
between now and later, when the method is actually executed.

While you can use any object that understands #value in those constructs,
it doesn’t mean you should. It is neat philosophically, but has little
practical value unless you get into meta programming.

BTW, the addition of Object>>value is relatively recent. As in, I remember
a time when it did not exist. I’m sure Andres does too, and he has good
reasons for cautioning against abusing it.

– Nessa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240612/e8ec7b82/attachment-0001.htm>