>From the slides:
"What is the difference between a block and a simple object understanding
#value?"
The slides give the wrong answer. The right answer is that
- a block can see the variables of the blocks, method, and object
containing it
which allows ENCAPSULATION of long term and short term state
- an object cannot see those variables, forcing long term and short term
state
to be dispersed to other objects, harming encapsulation.
The slides also say
" imagine passing a block around and want to accumulate information
◦ you can't!"
which is of course not really so. Consider
|b s|
b := [:state :argument | state nextPut: argument].
s := Summary new.
#(3 1 4 1 5 9) do: (b bindFirst: s).
s printOn: Transcript. Transcript cr.
That's actual working code and the output is
Summary(count: 6 min: 1 max: 9 mean: 3.833333333333333 sd:
2.994439290863428 skew: 1.044066600910494)
Far from "you can't", it's dead simple.
My library includes
#bindFirst:[bindSecond:[bindThird:]] #bindSecond:[bindThird:] #bindThird:
for binding any subset of the first three arguments of a block.
So far that's been enough.
The slides further say
"Adding behavior (i.e., offering another message) is impossible"
which is sort of true but misleading: you cannot add additional behaviour
to *an individual block*, but you CAN add additional behaviour to the class
it is an instance of. Which is how come I have #value:valueWithArguments:
#bindFirst: and its relatives, and a host of other combinators. It really
really
helps that I have a separate class for each block arity. For example, I
have
about 20 non-ANSI methods on TriadicBlock but about 50 on DyadicBlock.
The additional 30 on DyadicBlock would make no sense for TriadicBlock,
and smushing everything up into a single Block class would not work well.
That whole set of slides reads like a hymn of praise to Java nested classes,
which can do things blocks can't but on the other hand can't do things that
blocks can.
The issue we are discussing in this thread, of course, is not blocks as
such.
It isn't even blocks with many arguments. In
aBlock value: firstArgument valueWithArguments: restArguments
we have been given no reason to suppose that restArguments is long.
I still have a couple of stickers that Brian Marick gave me, reading
AN EXAMPLE WOULD BE GOOD ABOUT NOW.
I'd still like to know what the original poster wanted to DO with
value: firstArgument value: restArguments
^self valueWithArguments: {firstArgument} , restArguments
On Tue, 11 Apr 2023 at 04:25, Richard Sargent <rsarg...@5x5.on.ca> wrote:
> Excellent write up, Stephane!
>
> I will add that over the years, there have been many times (countless!)
> when developing/debugging involved a complex block and that turned out to
> be significant nuisance.
>
> I can elaborate on the details, but once a block gets passed around,
> revising it on the fly breaks debug and continue.
>
> Having a block comprise a single message send allows one to revise that
> method as and when needed.
>
>
>
>
>
> *From:* vwnc-requ...@lists.cs.illinois.edu <
> vwnc-requ...@lists.cs.illinois.edu> *On Behalf Of *
> stephane.duca...@free.fr
> *Sent:* April 10, 2023 07:03
> *To:* Any question about pharo is welcome <pharo-users@lists.pharo.org>
> *Cc:* v...@lists.cs.illinois.edu
> *Subject:* Re: [vwnc] [Pharo-users] Block evaluation with n+1 arguments
>
>
>
> BTW to me when a block needs too many arguments it feels like that an
> object has to be born :)
>
> With an object I can just sent or not a given extra argument.
>
>
>
> Now I do not know enough your specific context but what I learned is that
> complex blocks are difficult to follow, manipulate…
>
> so I keep block as simple as possible and else I create little objects.
>
>
>
>
>
> This is a little lectures from a super cool forthcoming mooc
>
>
>
>
> https://rmod-files.lille.inria.fr/DesignCoffeeClub/ForLearningLab/7-Lang-04-BlocksVsObjects.pdf
> <https://urldefense.com/v3/__https:/rmod-files.lille.inria.fr/DesignCoffeeClub/ForLearningLab/7-Lang-04-BlocksVsObjects.pdf__;!!DZ3fjg!7bRnSLpPY1OiW_EoNtvSDBVMfYN5owvLQjTs_FdNbynPLMw7hmdZCNifkawlO9Hz-NbVkGnnh37u3XIaEJEAHjFBHHppJxSeBgY$>
>
>
>
>
>
>
>
> On 6 Apr 2023, at 15:28, Steffen Märcker <merk...@web.de> wrote:
>
>
>
> Hi!
>
> I want to evaluate a block an argument 'arg1' and additional n arguments
> given in an array 'args'. The following code does the trick:
>
> block valueWithArguments: (Array with: arg1) , args.
>
> Is there a way to do this without the overhead of creating a new Array?
> (How) Can I add additional #value:value:[...] methods to BlockClosure that
> evaluate the block with n arguments directly without falling back to
> #valueWithArguments: ? If yes, what's the maximum?
>
> Cheers!
> Steffen
>
>
>
