Hi Christoph.

> ... but not Array new: 20 filledWith: 42.

That's what #new:withAll: is for.

> ... Instead, I would need to specify extra brackets that appear kind of redundant to me: ...

Because it is not required. Use #new:withAll:. :-) I would rather not over-engineer a specific interface if there are others for the job. On the idiomatic side, #new:withAll: would be preferred over #new:filledWith: for constant arguments.

And even #new:filledWith: has not been accepted for Trunk. So this discussion about Object >> #cull: needs a better example. ;-)

Best,
Marcel
Am 10.12.2019 13:06:19 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
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:


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/f62af6be/attachment.html>