This curiosity is fun, Christoph.  Some comments.

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 interface should be designed to be as rigid as it _can_ be, while still
meeting the requirements of those running the code.  As Nicolas alluded in
another email, it's much easier to relax constraints than impose them.
TSTTCPW really is a good axiom to try to strictly adhere to.


> 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.
>

I think saying its a "problem" might be overstating it.   Attempting to
sweeten the syntax as you suggest would introduce a new trade-off --
ambiguity with how one might otherwise make an Array filled with Blocks.


>
> 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.
>

I understand you on this point, however, #cull: arg when the arg will
_never_ be consumed, IMO, is a red flag warning that this "blurring" may be
trying to go one step too far.  #value is an "accessor", calculated or
not.  #cull: is a more-specific responsibility of a "behavioral" object --
a Block or MessageSend -- that implies "selection" or calculation.

Best,
  Chris


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