Hi Marcel,


I see this sentence of myself was ambiguous:


> This could improve the polymorphy between "evaluables" such as blocks or MessageSends and other objects. Example:

I meant: improve the polymorphy between, on the one hand, blocks, MessageSends & Co., and on the other hand, objects in general.

When I design an interface, I often wonder whether I should store into an accessor either a block or rather a normal object. A block has a more sophisticated syntax, while normal objects can't vary dependent on an argument.

An example: Let's assume Collections-mt.852 would be merged into Trunk (which uses #cull:).
Then I could say
Array new: 20 filledWith: [100 atRandom].
or even
Array new: 20 filledWith: [:i | i ** 2].
but not
Array new: 20 filledWith: 42.
Instead, I would need to specify extra brackets that appear kind of redundant to me:
Array new: 20 filledWith: [42].

Object >> #cull: would solve this problem.

It would be also analog to the implementation of Object >> #value, which allows you to do
self assert: [Boolean random].
as well as
self assert: Boolean random.
>From this point of view, every object is already evaluable today.


Looking forward to your thoughts - before or after 5.3 :-)


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 10. Dezember 2019 09:38:56
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Object >> #cull:

Hi Christoph,

let's discuss that after the 5.3 release.

> such as blocks or MessageSends

Well, then BlockClosure and MessageSend would be the place to add #cull:. There is no need to put it in Object because any class can choose to freely and dynamically participate in such a protocol. :-)

Best,
Marcel

Am 09.12.2019 18:51:35 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:

Hi all!


Just another, possibly crazy idea: What about implementing #cull:, #cull:cull: etc. on Object?


Object >> #cull: firstArg

    ^ self value


This could improve the polymorphy between "evaluables" such as blocks or MessageSends and other objects. Example:


[2 / 0] on: ZeroDivide do: Float infinity


Some current implementations that call both #isBlock and #cull: also reveal that there might be a small break in the interface. From #haltIf:

[cid:95ff5c48-deea-4916-916d-937c0382e78b]


Just wanted to share that thought :) In general, do you think blurring the differences between block and object in that way might be a good idea or rather a bad one? At least we already have implemented #value on Object.


Disclaimer: I know that in many cases, you should prefer a block for performance reasons/compiler optimization, but there is still a gap between the interfaces ...


Best,

Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191210/f2548f72/attachment.html>