I think I saw a coding pattern a while ago that allows you to do the
following:
cond1 , cond2 , cond3 , cond4
And providing a kind of folding selector condition #and: you would get:
[ cond1 and: [ cond2 and: [ cond3 and: [ cond4 ] ] ] ].
for example:
conditions := [ : each | each firstName = '
On October 23, 2019 5:46:50 AM PDT, "p...@highoctane.be"
wrote:
>On Wed, 23 Oct 2019, 14:25 Kasper Osterbye,
>wrote:
>
>> On Wed, Oct 23, 2019 at 2:21 PM p...@highoctane.be
>
>> wrote:
>>
>>> It is like Object>>in: aBlock no?
>>>
>> Yes.
>>
>> But because it is an operator, you can write "obj
No kind of object does what you want.
You cannot do 3 3
or #x #y
As for [:x | x + 1] 3, what would be the *point* of doing this?
What is the block suppose to *do* with the 3? Do you want to extend this
to [:x :y | x + y] 3 4 ? If not, why not? What about [3+4] "what to put
Hi Johan,
That is nice indeed. It is good to see that you have fun learning Pharo
Smalltalk.
Can you do it ? Of course, you can do what you want, Pharo Smalltalk is a
highly flexible environment.
Key to its simplicity are its ultra simple syntax which hits a magical optimum
between simplicity
Looks nice!
Just my two cents. To make function comopostion work with multiple
aruments, I implemented * as:
BlockClosure class>>* first
^ComposedFunction first: first second: self
And use a dedicated class to make multiple arguments work:
ComposedFunction>>value: arg
^second value
Hi again!
Just putting it out there for anyone interested.
What I did was define the following in Object:
|> aBlock
^ [ :x | x => self => aBlock ]
and also:
=> msg
^ msg value: self
This enabled me to compose like this (I know I probably violate every rule
in the book, whatev
On Wed, 23 Oct 2019, 14:25 Kasper Osterbye,
wrote:
> On Wed, Oct 23, 2019 at 2:21 PM p...@highoctane.be
> wrote:
>
>> It is like Object>>in: aBlock no?
>>
> Yes.
>
> But because it is an operator, you can write "obj => block => block =>
> block".
> You can not write "obj in: block in: block in:
On Wed, Oct 23, 2019 at 2:21 PM p...@highoctane.be
wrote:
> It is like Object>>in: aBlock no?
>
Yes.
But because it is an operator, you can write "obj => block => block =>
block".
You can not write "obj in: block in: block in: block", because smalltalk
will think it is a selector named "in:in:in
It is like Object>>in: aBlock no?
On Wed, 23 Oct 2019, 10:27 Kasper Osterbye,
wrote:
> You can define a method "=>" in Object as:
>
> => aBlock
> ^ aBlock value: self
>
> That would allow you to write expressions like this:
> 7 => [ :x | x+3 ] => [ :x| x*3 ],
>
> if you further define "=>" in
You can define a method "=>" in Object as:
=> aBlock
^ aBlock value: self
That would allow you to write expressions like this:
7 => [ :x | x+3 ] => [ :x| x*3 ],
if you further define "=>" in Array as:
=> aBlock
^ aBlock valueWithArguments: self
you are able to write your example:
(([ :f :g |
Hi,
The first part could be done, but with limitations.
- you won't be able to value it with anything but variables names
- those variables cannot have the same name as a method of BlockClosure
- I don't think this can be implemented by default in Pharo, as it is
kinda "dangerous"
- might
There's no way you could use an integer (or any number) as a selector.
So what you can do if you want to avoid using the "wordy" #value: selector
is to implement your own selector in BlockClosure.
It could be a #v: selector (so it is still a keyword selector) or a symbol
such as #<< that ends up
Hello fellow Pharoians (?) from a lonely Swede.
I just found out about Pharo (and Smalltalk) two days ago and I'm already
loving it :)
However, there is a behavior I would like to change, or be enlightened about
how it could be done.
As I understand it (bear with me) BlockClosure from Kernel-Meth
13 matches
Mail list logo
