Smalltalk › Pharo › Pharo Smalltalk Developers

#valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Stefan Marr-3

#valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

Hi:

I am trying to understand the different between and perhaps origin of BlockClosure>>#valueWithPossibleArgs: and BlockClosure>>#valueWithEnoughArguments:

I am trying to decide which of the two I need for SOMns.

The first one has seen more recent changes, when looking at the Pharo 6.1 download:

valueWithPossibleArgs: anArray —> 2/12/2017 StephaneDucasse
valueWithEnoughArguments: anArray —> 3/11/2001 nk

While they have rather different implementations, they seem to behave identically, as far as I could tell using the following example:

blocks := {
[ { } ].
[:a | { a } ].
[:a :b | { a. b } ].
[:a :b :c | { a. b. c } ]
}.

blocks collect: [:b | b valueWithPossibleArgs: {1}].
blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
blocks collect: [:b | b valueWithEnoughArguments: {1}].
blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].

I was also wondering how they relate to #cull:*

One of the major differences seems to be that valueWithP* and valueWithE* are both injecting nil for absent arguments, while normal #value* and #cull* methods signal an error.
Is there a specific use case why one wouldn’t want to be strict here as well, but instead inject nils?

Any comments or pointer appreciated.

Thanks
Stefan

--
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/

Clément Béra

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

Hi,

It seems the two methods have exactly the same behavior indeed.

valueWithPossibleArgs: anArray
valueWithEnoughArguments: anArray

One was edited recently but I think it's only to change the comment, they're both very old. My guess is that there are two for compatibility purpose (One is the selector that is considered as the most relevant that should be used, the other one is the one also present in other Smalltalks so we have it for cross-Smalltalk librairies or something like that), but only one is really needed. If you need only the concept for SOM-NS you can just implement one, if you want to be compatible with different Smalltalk lib implement both.

All use-cases of these methods I have found do not inject nils, they expect the block to have a number of arguments of the block less or equal to the number of parameters in the argument array. I would say they're used as #cullWithArguments: but for some reason other selector names were preferred.

Now, as you mentioned, these two methods are more than just cullWithArguments: since they inject nils if there are not enough parameters. To me it looks incorrect to do so because then while debugging your code you will get issues due to those injected nils and it will be tedious for the application programmer to track the problem down to these two methods.

There a few use-cases for nil injection though. Typically when changing existing frameworks in multiple repositories, it may be that during the update process the change to the caller is installed before the change of the callee, and if the code is actually used (code in UI for instance), injecting nils might avoid system break-down. Another use-case is for compatibility with frameworks using the nil injection, but I can't find a framework doing that right now.

Honestly, I would not implement the nil injection, but maybe some one else has a different point of view.

On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <[hidden email]> wrote:

Hi:

I am trying to understand the different between and perhaps origin of BlockClosure>>#valueWithPossibleArgs: and BlockClosure>>#valueWithEnoughArguments:

I am trying to decide which of the two I need for SOMns.

The first one has seen more recent changes, when looking at the Pharo 6.1 download:

valueWithPossibleArgs: anArray —> 2/12/2017 StephaneDucasse
valueWithEnoughArguments: anArray —> 3/11/2001 nk

While they have rather different implementations, they seem to behave identically, as far as I could tell using the following example:

blocks := {
[ { } ].
[:a | { a } ].
[:a :b | { a. b } ].
[:a :b :c | { a. b. c } ]
}.

blocks collect: [:b | b valueWithPossibleArgs: {1}].
blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
blocks collect: [:b | b valueWithEnoughArguments: {1}].
blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].

I was also wondering how they relate to #cull:*

One of the major differences seems to be that valueWithP* and valueWithE* are both injecting nil for absent arguments, while normal #value* and #cull* methods signal an error.
Is there a specific use case why one wouldn’t want to be strict here as well, but instead inject nils?

Any comments or pointer appreciated.

Thanks
Stefan

--
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/

Clément Béra

Pharo consortium engineer

https://clementbera.wordpress.com/

Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Stefan Marr-3

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

Hi Clement:

Thanks for looking into this!

> On 19 Feb 2018, at 11:43, Clément Bera <[hidden email]> wrote:
>
> they're both very old. My guess is that there are two for compatibility purpose

Ok, good to know. Thanks.

> All use-cases of these methods I have found do not inject nils, they expect the block to have a number of arguments of the block less or equal to the number of parameters in the argument array. I would say they’re used as #cullWithArguments: but for some reason other selector names were preferred.
> [...]
> There a few use-cases for nil injection though. Typically when changing existing frameworks in multiple repositories, it may be that during the update process the change to the caller is installed before the change of the callee, and if the code is actually used (code in UI for instance), injecting nils might avoid system break-down. Another use-case is for compatibility with frameworks using the nil injection, but I can’t find a framework doing that right now.

Ok, great.

In the end, I only added #cullArguments: instead of the #valueWith* variants [1].
The naming seems to communicate more clearly the expected semantics, and it’s different from the previous ones. So, in case it turns out someone needs those with nil injecting semantics, they could be added later.

Thanks
Stefan

[1] https://github.com/smarr/SOMns/pull/215/files#diff-8dd7efb0aab92cd4b39e0bf845dea9a2R621

--
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/

Mariano Martinez Peck

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

In reply to this post by Stefan Marr-3

On Fri, Feb 16, 2018 at 2:25 PM, Stefan Marr <[hidden email]> wrote:

Hi:

I am trying to understand the different between and perhaps origin of BlockClosure>>#valueWithPossibleArgs: and BlockClosure>>#valueWithEnoughArguments:

I am trying to decide which of the two I need for SOMns.

The first one has seen more recent changes, when looking at the Pharo 6.1 download:

valueWithPossibleArgs: anArray —> 2/12/2017 StephaneDucasse
valueWithEnoughArguments: anArray —> 3/11/2001 nk

While they have rather different implementations, they seem to behave identically, as far as I could tell using the following example:

blocks := {
[ { } ].
[:a | { a } ].
[:a :b | { a. b } ].
[:a :b :c | { a. b. c } ]
}.

blocks collect: [:b | b valueWithPossibleArgs: {1}].
blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
blocks collect: [:b | b valueWithEnoughArguments: {1}].
blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].

I was also wondering how they relate to #cull:*

One of the major differences seems to be that valueWithP* and valueWithE* are both injecting nil for absent arguments, while normal #value* and #cull* methods signal an error.
Is there a specific use case why one wouldn’t want to be strict here as well, but instead inject nils?

I guess it's because we offer both flavors. If you see valueWithArguments: you will see it does throw errors like #value* / #cull* do.

Any comments or pointer appreciated.

Thanks
Stefan

--
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/

Mariano
http://marianopeck.wordpress.com

Stefan Marr-3

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

Hi Mariano:

> On 19 Feb 2018, at 20:09, Mariano Martinez Peck <[hidden email]> wrote:
>
> I guess it's because we offer both flavors. If you see valueWithArguments: you will see it does throw errors like #value* / #cull* do.

Did you try my examples?
I don’t think this is correct.
In Pharo 6.1, #valueWithArguments: doesn’t throw any errors as far as I can see. It inserts nil for absent arguments however.

This is what I tried:

blocks := {
[ { } ].
[:a | { a } ].
[:a :b | { a. b } ].
[:a :b :c | { a. b. c } ]
}.

blocks collect: [:b | b valueWithPossibleArgs: {1}].
blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
blocks collect: [:b | b valueWithEnoughArguments: {1}].
blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].

Best regards
Stefan

--
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/

Stefan Marr-3

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

Ah, sorry, yes #valueWithArguments: does throw errors.

Best regards
Stefan

> On 19 Feb 2018, at 20:17, Stefan Marr <[hidden email]> wrote:
>
> Hi Mariano:
>
>> On 19 Feb 2018, at 20:09, Mariano Martinez Peck <[hidden email]> wrote:
>>
>> I guess it's because we offer both flavors. If you see valueWithArguments: you will see it does throw errors like #value* / #cull* do.
>
> Did you try my examples?
> I don’t think this is correct.
> In Pharo 6.1, #valueWithArguments: doesn’t throw any errors as far as I can see. It inserts nil for absent arguments however.
>
> This is what I tried:
>
> blocks := {
> [ { } ].
> [:a | { a } ].
> [:a :b | { a. b } ].
> [:a :b :c | { a. b. c } ]
> }.
>
> blocks collect: [:b | b valueWithPossibleArgs: {1}].
> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
> blocks collect: [:b | b valueWithEnoughArguments: {1}].
> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].
>
>
> Best regards
> Stefan
>
>
> --
> Stefan Marr
> School of Computing, University of Kent
> http://stefan-marr.de/research/
>
>

--
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/

Stephane Ducasse-3

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

In reply to this post by Clément Béra

Clement

can you open a bug entry so that we clean this situation?

Stef

On Mon, Feb 19, 2018 at 12:43 PM, Clément Bera <[hidden email]> wrote:

> Hi,
>
> It seems the two methods have exactly the same behavior indeed.
> valueWithPossibleArgs: anArray
> valueWithEnoughArguments: anArray
>
> One was edited recently but I think it's only to change the comment, they're
> both very old. My guess is that there are two for compatibility purpose (One
> is the selector that is considered as the most relevant that should be used,
> the other one is the one also present in other Smalltalks so we have it for
> cross-Smalltalk librairies or something like that), but only one is really
> needed. If you need only the concept for SOM-NS you can just implement one,
> if you want to be compatible with different Smalltalk lib implement both.
>
> All use-cases of these methods I have found do not inject nils, they expect
> the block to have a number of arguments of the block less or equal to the
> number of parameters in the argument array. I would say they're used as
> #cullWithArguments: but for some reason other selector names were preferred.
>
> Now, as you mentioned, these two methods are more than just
> cullWithArguments: since they inject nils if there are not enough
> parameters. To me it looks incorrect to do so because then while debugging
> your code you will get issues due to those injected nils and it will be
> tedious for the application programmer to track the problem down to these
> two methods.
>
> There a few use-cases for nil injection though. Typically when changing
> existing frameworks in multiple repositories, it may be that during the
> update process the change to the caller is installed before the change of
> the callee, and if the code is actually used (code in UI for instance),
> injecting nils might avoid system break-down. Another use-case is for
> compatibility with frameworks using the nil injection, but I can't find a
> framework doing that right now.
>
> Honestly, I would not implement the nil injection, but maybe some one else
> has a different point of view.
>
> On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <[hidden email]>
> wrote:
>>
>> Hi:
>>
>> I am trying to understand the different between and perhaps origin of
>> BlockClosure>>#valueWithPossibleArgs: and
>> BlockClosure>>#valueWithEnoughArguments:
>>
>> I am trying to decide which of the two I need for SOMns.
>>
>> The first one has seen more recent changes, when looking at the Pharo 6.1
>> download:
>>
>> valueWithPossibleArgs: anArray —> 2/12/2017 StephaneDucasse
>> valueWithEnoughArguments: anArray —> 3/11/2001 nk
>>
>> While they have rather different implementations, they seem to behave
>> identically, as far as I could tell using the following example:
>>
>> blocks := {
>> [ { } ].
>> [:a | { a } ].
>> [:a :b | { a. b } ].
>> [:a :b :c | { a. b. c } ]
>> }.
>>
>> blocks collect: [:b | b valueWithPossibleArgs: {1}].
>> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
>> blocks collect: [:b | b valueWithEnoughArguments: {1}].
>> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].
>>
>> I was also wondering how they relate to #cull:*
>>
>> One of the major differences seems to be that valueWithP* and valueWithE*
>> are both injecting nil for absent arguments, while normal #value* and #cull*
>> methods signal an error.
>> Is there a specific use case why one wouldn’t want to be strict here as
>> well, but instead inject nils?
>>
>> Any comments or pointer appreciated.
>>
>> Thanks
>> Stefan
>>
>>
>> --
>> Stefan Marr
>> School of Computing, University of Kent
>> http://stefan-marr.de/research/
>>
>>
>>
>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Clément Béra

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <[hidden email]> wrote:

Clement

can you open a bug entry so that we clean this situation?

What is the bug? You want to merge the two selectors and break compatibility with frameworks using the removed one?

Stef

On Mon, Feb 19, 2018 at 12:43 PM, Clément Bera <[hidden email]> wrote:
> Hi,
>
> It seems the two methods have exactly the same behavior indeed.
> valueWithPossibleArgs: anArray
> valueWithEnoughArguments: anArray
>
> One was edited recently but I think it's only to change the comment, they're
> both very old. My guess is that there are two for compatibility purpose (One
> is the selector that is considered as the most relevant that should be used,
> the other one is the one also present in other Smalltalks so we have it for
> cross-Smalltalk librairies or something like that), but only one is really
> needed. If you need only the concept for SOM-NS you can just implement one,
> if you want to be compatible with different Smalltalk lib implement both.
>
> All use-cases of these methods I have found do not inject nils, they expect
> the block to have a number of arguments of the block less or equal to the
> number of parameters in the argument array. I would say they're used as
> #cullWithArguments: but for some reason other selector names were preferred.
>
> Now, as you mentioned, these two methods are more than just
> cullWithArguments: since they inject nils if there are not enough
> parameters. To me it looks incorrect to do so because then while debugging
> your code you will get issues due to those injected nils and it will be
> tedious for the application programmer to track the problem down to these
> two methods.
>
> There a few use-cases for nil injection though. Typically when changing
> existing frameworks in multiple repositories, it may be that during the
> update process the change to the caller is installed before the change of
> the callee, and if the code is actually used (code in UI for instance),
> injecting nils might avoid system break-down. Another use-case is for
> compatibility with frameworks using the nil injection, but I can't find a
> framework doing that right now.
>
> Honestly, I would not implement the nil injection, but maybe some one else
> has a different point of view.
>
> On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <[hidden email]>
> wrote:
>>
>> Hi:
>>
>> I am trying to understand the different between and perhaps origin of
>> BlockClosure>>#valueWithPossibleArgs: and
>> BlockClosure>>#valueWithEnoughArguments:
>>
>> I am trying to decide which of the two I need for SOMns.
>>
>> The first one has seen more recent changes, when looking at the Pharo 6.1
>> download:
>>
>> valueWithPossibleArgs: anArray —> 2/12/2017 StephaneDucasse
>> valueWithEnoughArguments: anArray —> 3/11/2001 nk
>>
>> While they have rather different implementations, they seem to behave
>> identically, as far as I could tell using the following example:
>>
>> blocks := {
>> [ { } ].
>> [:a | { a } ].
>> [:a :b | { a. b } ].
>> [:a :b :c | { a. b. c } ]
>> }.
>>
>> blocks collect: [:b | b valueWithPossibleArgs: {1}].
>> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
>> blocks collect: [:b | b valueWithEnoughArguments: {1}].
>> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].
>>
>> I was also wondering how they relate to #cull:*
>>
>> One of the major differences seems to be that valueWithP* and valueWithE*
>> are both injecting nil for absent arguments, while normal #value* and #cull*
>> methods signal an error.
>> Is there a specific use case why one wouldn’t want to be strict here as
>> well, but instead inject nils?
>>
>> Any comments or pointer appreciated.
>>
>> Thanks
>> Stefan
>>
>>
>> --
>> Stefan Marr
>> School of Computing, University of Kent
>> http://stefan-marr.de/research/
>>
>>
>>
>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Clément Béra

Pharo consortium engineer

https://clementbera.wordpress.com/

Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Sven Van Caekenberghe-2

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

> On 22 Feb 2018, at 10:41, Clément Bera <[hidden email]> wrote:
>
>
>
> On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <[hidden email]> wrote:
> Clement
>
> can you open a bug entry so that we clean this situation?
>
>
> What is the bug?

Having two selectors doing the same thing is bad and confuses everybody. So that is a 'bug'.

> You want to merge the two selectors and break compatibility with frameworks using the removed one?

Either we keep on adding cruft (or leaving cruft in place) in the sake of backwards compatibility or be do something about it. It is not hard to fix a couple of senders. It could be done more softly with a deprecation.

Cleanups at the level of Object are particularly valuable.

> Stef
>
> On Mon, Feb 19, 2018 at 12:43 PM, Clément Bera <[hidden email]> wrote:
> > Hi,
> >
> > It seems the two methods have exactly the same behavior indeed.
> > valueWithPossibleArgs: anArray
> > valueWithEnoughArguments: anArray
> >
> > One was edited recently but I think it's only to change the comment, they're
> > both very old. My guess is that there are two for compatibility purpose (One
> > is the selector that is considered as the most relevant that should be used,
> > the other one is the one also present in other Smalltalks so we have it for
> > cross-Smalltalk librairies or something like that), but only one is really
> > needed. If you need only the concept for SOM-NS you can just implement one,
> > if you want to be compatible with different Smalltalk lib implement both.
> >
> > All use-cases of these methods I have found do not inject nils, they expect
> > the block to have a number of arguments of the block less or equal to the
> > number of parameters in the argument array. I would say they're used as
> > #cullWithArguments: but for some reason other selector names were preferred.
> >
> > Now, as you mentioned, these two methods are more than just
> > cullWithArguments: since they inject nils if there are not enough
> > parameters. To me it looks incorrect to do so because then while debugging
> > your code you will get issues due to those injected nils and it will be
> > tedious for the application programmer to track the problem down to these
> > two methods.
> >
> > There a few use-cases for nil injection though. Typically when changing
> > existing frameworks in multiple repositories, it may be that during the
> > update process the change to the caller is installed before the change of
> > the callee, and if the code is actually used (code in UI for instance),
> > injecting nils might avoid system break-down. Another use-case is for
> > compatibility with frameworks using the nil injection, but I can't find a
> > framework doing that right now.
> >
> > Honestly, I would not implement the nil injection, but maybe some one else
> > has a different point of view.
> >
> > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <[hidden email]>
> > wrote:
> >>
> >> Hi:
> >>
> >> I am trying to understand the different between and perhaps origin of
> >> BlockClosure>>#valueWithPossibleArgs: and
> >> BlockClosure>>#valueWithEnoughArguments:
> >>
> >> I am trying to decide which of the two I need for SOMns.
> >>
> >> The first one has seen more recent changes, when looking at the Pharo 6.1
> >> download:
> >>
> >> valueWithPossibleArgs: anArray —> 2/12/2017 StephaneDucasse
> >> valueWithEnoughArguments: anArray —> 3/11/2001 nk
> >>
> >> While they have rather different implementations, they seem to behave
> >> identically, as far as I could tell using the following example:
> >>
> >> blocks := {
> >> [ { } ].
> >> [:a | { a } ].
> >> [:a :b | { a. b } ].
> >> [:a :b :c | { a. b. c } ]
> >> }.
> >>
> >> blocks collect: [:b | b valueWithPossibleArgs: {1}].
> >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
> >> blocks collect: [:b | b valueWithEnoughArguments: {1}].
> >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].
> >>
> >> I was also wondering how they relate to #cull:*
> >>
> >> One of the major differences seems to be that valueWithP* and valueWithE*
> >> are both injecting nil for absent arguments, while normal #value* and #cull*
> >> methods signal an error.
> >> Is there a specific use case why one wouldn’t want to be strict here as
> >> well, but instead inject nils?
> >>
> >> Any comments or pointer appreciated.
> >>
> >> Thanks
> >> Stefan
> >>
> >>
> >> --
> >> Stefan Marr
> >> School of Computing, University of Kent
> >> http://stefan-marr.de/research/
> >>
> >>
> >>
> >
> >
> >
> > --
> > Clément Béra
> > Pharo consortium engineer
> > https://clementbera.wordpress.com/
> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Stephane Ducasse-3

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

Thanks Sven
I thought that suddenly I was an idiot.

On Thu, Feb 22, 2018 at 11:47 AM, Sven Van Caekenberghe <[hidden email]> wrote:

>
>
>> On 22 Feb 2018, at 10:41, Clément Bera <[hidden email]> wrote:
>>
>>
>>
>> On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <[hidden email]> wrote:
>> Clement
>>
>> can you open a bug entry so that we clean this situation?
>>
>>
>> What is the bug?
>
> Having two selectors doing the same thing is bad and confuses everybody. So that is a 'bug'.
>
>> You want to merge the two selectors and break compatibility with frameworks using the removed one?
>
> Either we keep on adding cruft (or leaving cruft in place) in the sake of backwards compatibility or be do something about it. It is not hard to fix a couple of senders. It could be done more softly with a deprecation.
>
> Cleanups at the level of Object are particularly valuable.
>
>> Stef
>>
>> On Mon, Feb 19, 2018 at 12:43 PM, Clément Bera <[hidden email]> wrote:
>> > Hi,
>> >
>> > It seems the two methods have exactly the same behavior indeed.
>> > valueWithPossibleArgs: anArray
>> > valueWithEnoughArguments: anArray
>> >
>> > One was edited recently but I think it's only to change the comment, they're
>> > both very old. My guess is that there are two for compatibility purpose (One
>> > is the selector that is considered as the most relevant that should be used,
>> > the other one is the one also present in other Smalltalks so we have it for
>> > cross-Smalltalk librairies or something like that), but only one is really
>> > needed. If you need only the concept for SOM-NS you can just implement one,
>> > if you want to be compatible with different Smalltalk lib implement both.
>> >
>> > All use-cases of these methods I have found do not inject nils, they expect
>> > the block to have a number of arguments of the block less or equal to the
>> > number of parameters in the argument array. I would say they're used as
>> > #cullWithArguments: but for some reason other selector names were preferred.
>> >
>> > Now, as you mentioned, these two methods are more than just
>> > cullWithArguments: since they inject nils if there are not enough
>> > parameters. To me it looks incorrect to do so because then while debugging
>> > your code you will get issues due to those injected nils and it will be
>> > tedious for the application programmer to track the problem down to these
>> > two methods.
>> >
>> > There a few use-cases for nil injection though. Typically when changing
>> > existing frameworks in multiple repositories, it may be that during the
>> > update process the change to the caller is installed before the change of
>> > the callee, and if the code is actually used (code in UI for instance),
>> > injecting nils might avoid system break-down. Another use-case is for
>> > compatibility with frameworks using the nil injection, but I can't find a
>> > framework doing that right now.
>> >
>> > Honestly, I would not implement the nil injection, but maybe some one else
>> > has a different point of view.
>> >
>> > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <[hidden email]>
>> > wrote:
>> >>
>> >> Hi:
>> >>
>> >> I am trying to understand the different between and perhaps origin of
>> >> BlockClosure>>#valueWithPossibleArgs: and
>> >> BlockClosure>>#valueWithEnoughArguments:
>> >>
>> >> I am trying to decide which of the two I need for SOMns.
>> >>
>> >> The first one has seen more recent changes, when looking at the Pharo 6.1
>> >> download:
>> >>
>> >> valueWithPossibleArgs: anArray —> 2/12/2017 StephaneDucasse
>> >> valueWithEnoughArguments: anArray —> 3/11/2001 nk
>> >>
>> >> While they have rather different implementations, they seem to behave
>> >> identically, as far as I could tell using the following example:
>> >>
>> >> blocks := {
>> >> [ { } ].
>> >> [:a | { a } ].
>> >> [:a :b | { a. b } ].
>> >> [:a :b :c | { a. b. c } ]
>> >> }.
>> >>
>> >> blocks collect: [:b | b valueWithPossibleArgs: {1}].
>> >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
>> >> blocks collect: [:b | b valueWithEnoughArguments: {1}].
>> >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].
>> >>
>> >> I was also wondering how they relate to #cull:*
>> >>
>> >> One of the major differences seems to be that valueWithP* and valueWithE*
>> >> are both injecting nil for absent arguments, while normal #value* and #cull*
>> >> methods signal an error.
>> >> Is there a specific use case why one wouldn’t want to be strict here as
>> >> well, but instead inject nils?
>> >>
>> >> Any comments or pointer appreciated.
>> >>
>> >> Thanks
>> >> Stefan
>> >>
>> >>
>> >> --
>> >> Stefan Marr
>> >> School of Computing, University of Kent
>> >> http://stefan-marr.de/research/
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Clément Béra
>> > Pharo consortium engineer
>> > https://clementbera.wordpress.com/
>> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>>
>>
>>
>>
>> --
>> Clément Béra
>> Pharo consortium engineer
>> https://clementbera.wordpress.com/
>> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>

Guillermo Polito

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

++++++999^1000 :)

On Fri, Feb 23, 2018 at 7:32 AM, Stephane Ducasse <[hidden email]> wrote:

Thanks Sven
I thought that suddenly I was an idiot.

On Thu, Feb 22, 2018 at 11:47 AM, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
>> On 22 Feb 2018, at 10:41, Clément Bera <[hidden email]> wrote:
>>
>>
>>
>> On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <[hidden email]> wrote:
>> Clement
>>
>> can you open a bug entry so that we clean this situation?
>>
>>
>> What is the bug?
>
> Having two selectors doing the same thing is bad and confuses everybody. So that is a 'bug'.
>
>> You want to merge the two selectors and break compatibility with frameworks using the removed one?
>
> Either we keep on adding cruft (or leaving cruft in place) in the sake of backwards compatibility or be do something about it. It is not hard to fix a couple of senders. It could be done more softly with a deprecation.
>
> Cleanups at the level of Object are particularly valuable.
>
>> Stef
>>
>> On Mon, Feb 19, 2018 at 12:43 PM, Clément Bera <[hidden email]> wrote:
>> > Hi,
>> >
>> > It seems the two methods have exactly the same behavior indeed.
>> > valueWithPossibleArgs: anArray
>> > valueWithEnoughArguments: anArray
>> >
>> > One was edited recently but I think it's only to change the comment, they're
>> > both very old. My guess is that there are two for compatibility purpose (One
>> > is the selector that is considered as the most relevant that should be used,
>> > the other one is the one also present in other Smalltalks so we have it for
>> > cross-Smalltalk librairies or something like that), but only one is really
>> > needed. If you need only the concept for SOM-NS you can just implement one,
>> > if you want to be compatible with different Smalltalk lib implement both.
>> >
>> > All use-cases of these methods I have found do not inject nils, they expect
>> > the block to have a number of arguments of the block less or equal to the
>> > number of parameters in the argument array. I would say they're used as
>> > #cullWithArguments: but for some reason other selector names were preferred.
>> >
>> > Now, as you mentioned, these two methods are more than just
>> > cullWithArguments: since they inject nils if there are not enough
>> > parameters. To me it looks incorrect to do so because then while debugging
>> > your code you will get issues due to those injected nils and it will be
>> > tedious for the application programmer to track the problem down to these
>> > two methods.
>> >
>> > There a few use-cases for nil injection though. Typically when changing
>> > existing frameworks in multiple repositories, it may be that during the
>> > update process the change to the caller is installed before the change of
>> > the callee, and if the code is actually used (code in UI for instance),
>> > injecting nils might avoid system break-down. Another use-case is for
>> > compatibility with frameworks using the nil injection, but I can't find a
>> > framework doing that right now.
>> >
>> > Honestly, I would not implement the nil injection, but maybe some one else
>> > has a different point of view.
>> >
>> > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <[hidden email]>
>> > wrote:
>> >>
>> >> Hi:
>> >>
>> >> I am trying to understand the different between and perhaps origin of
>> >> BlockClosure>>#valueWithPossibleArgs: and
>> >> BlockClosure>>#valueWithEnoughArguments:
>> >>
>> >> I am trying to decide which of the two I need for SOMns.
>> >>
>> >> The first one has seen more recent changes, when looking at the Pharo 6.1
>> >> download:
>> >>
>> >> valueWithPossibleArgs: anArray —> 2/12/2017 StephaneDucasse
>> >> valueWithEnoughArguments: anArray —> 3/11/2001 nk
>> >>
>> >> While they have rather different implementations, they seem to behave
>> >> identically, as far as I could tell using the following example:
>> >>
>> >> blocks := {
>> >> [ { } ].
>> >> [:a | { a } ].
>> >> [:a :b | { a. b } ].
>> >> [:a :b :c | { a. b. c } ]
>> >> }.
>> >>
>> >> blocks collect: [:b | b valueWithPossibleArgs: {1}].
>> >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
>> >> blocks collect: [:b | b valueWithEnoughArguments: {1}].
>> >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].
>> >>
>> >> I was also wondering how they relate to #cull:*
>> >>
>> >> One of the major differences seems to be that valueWithP* and valueWithE*
>> >> are both injecting nil for absent arguments, while normal #value* and #cull*
>> >> methods signal an error.
>> >> Is there a specific use case why one wouldn’t want to be strict here as
>> >> well, but instead inject nils?
>> >>
>> >> Any comments or pointer appreciated.
>> >>
>> >> Thanks
>> >> Stefan
>> >>
>> >>
>> >> --
>> >> Stefan Marr
>> >> School of Computing, University of Kent
>> >> http://stefan-marr.de/research/
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Clément Béra
>> > Pharo consortium engineer
>> > https://clementbera.wordpress.com/
>> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>>
>>
>>
>>
>> --
>> Clément Béra
>> Pharo consortium engineer
>> https://clementbera.wordpress.com/
>> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Clément Béra

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

In reply to this post by Sven Van Caekenberghe-2

On Thu, Feb 22, 2018 at 11:47 AM, Sven Van Caekenberghe <[hidden email]> wrote:

> On 22 Feb 2018, at 10:41, Clément Bera <[hidden email]> wrote:
>
>
>
> On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <[hidden email]> wrote:
> Clement
>
> can you open a bug entry so that we clean this situation?
>
>
> What is the bug?

Having two selectors doing the same thing is bad and confuses everybody. So that is a 'bug'.

> You want to merge the two selectors and break compatibility with frameworks using the removed one?

Either we keep on adding cruft (or leaving cruft in place) in the sake of backwards compatibility or be do something about it. It is not hard to fix a couple of senders. It could be done more softly with a deprecation.

Cleanups at the level of Object are particularly valuable.

Ok.

Is the nil injection a feature or a bug too ? Should it be removed ?

> Stef
>
> On Mon, Feb 19, 2018 at 12:43 PM, Clément Bera <[hidden email]> wrote:
> > Hi,
> >
> > It seems the two methods have exactly the same behavior indeed.
> > valueWithPossibleArgs: anArray
> > valueWithEnoughArguments: anArray
> >
> > One was edited recently but I think it's only to change the comment, they're
> > both very old. My guess is that there are two for compatibility purpose (One
> > is the selector that is considered as the most relevant that should be used,
> > the other one is the one also present in other Smalltalks so we have it for
> > cross-Smalltalk librairies or something like that), but only one is really
> > needed. If you need only the concept for SOM-NS you can just implement one,
> > if you want to be compatible with different Smalltalk lib implement both.
> >
> > All use-cases of these methods I have found do not inject nils, they expect
> > the block to have a number of arguments of the block less or equal to the
> > number of parameters in the argument array. I would say they're used as
> > #cullWithArguments: but for some reason other selector names were preferred.
> >
> > Now, as you mentioned, these two methods are more than just
> > cullWithArguments: since they inject nils if there are not enough
> > parameters. To me it looks incorrect to do so because then while debugging
> > your code you will get issues due to those injected nils and it will be
> > tedious for the application programmer to track the problem down to these
> > two methods.
> >
> > There a few use-cases for nil injection though. Typically when changing
> > existing frameworks in multiple repositories, it may be that during the
> > update process the change to the caller is installed before the change of
> > the callee, and if the code is actually used (code in UI for instance),
> > injecting nils might avoid system break-down. Another use-case is for
> > compatibility with frameworks using the nil injection, but I can't find a
> > framework doing that right now.
> >
> > Honestly, I would not implement the nil injection, but maybe some one else
> > has a different point of view.
> >
> > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <[hidden email]>
> > wrote:
> >>
> >> Hi:
> >>
> >> I am trying to understand the different between and perhaps origin of
> >> BlockClosure>>#valueWithPossibleArgs: and
> >> BlockClosure>>#valueWithEnoughArguments:
> >>
> >> I am trying to decide which of the two I need for SOMns.
> >>
> >> The first one has seen more recent changes, when looking at the Pharo 6.1
> >> download:
> >>
> >> valueWithPossibleArgs: anArray —> 2/12/2017 StephaneDucasse
> >> valueWithEnoughArguments: anArray —> 3/11/2001 nk
> >>
> >> While they have rather different implementations, they seem to behave
> >> identically, as far as I could tell using the following example:
> >>
> >> blocks := {
> >> [ { } ].
> >> [:a | { a } ].
> >> [:a :b | { a. b } ].
> >> [:a :b :c | { a. b. c } ]
> >> }.
> >>
> >> blocks collect: [:b | b valueWithPossibleArgs: {1}].
> >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
> >> blocks collect: [:b | b valueWithEnoughArguments: {1}].
> >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].
> >>
> >> I was also wondering how they relate to #cull:*
> >>
> >> One of the major differences seems to be that valueWithP* and valueWithE*
> >> are both injecting nil for absent arguments, while normal #value* and #cull*
> >> methods signal an error.
> >> Is there a specific use case why one wouldn’t want to be strict here as
> >> well, but instead inject nils?
> >>
> >> Any comments or pointer appreciated.
> >>
> >> Thanks
> >> Stefan
> >>
> >>
> >> --
> >> Stefan Marr
> >> School of Computing, University of Kent
> >> http://stefan-marr.de/research/
> >>
> >>
> >>
> >
> >
> >
> > --
> > Clément Béra
> > Pharo consortium engineer
> > https://clementbera.wordpress.com/
> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Clément Béra

Pharo consortium engineer

https://clementbera.wordpress.com/

Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Stephan Eggermont-3

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

In reply to this post by Sven Van Caekenberghe-2

Sven Van Caekenberghe <[hidden email]> wrote:

> Either we keep on adding cruft (or leaving cruft in place) in the sake of
> backwards compatibility or be do something about it. It is not hard to
> fix a couple of senders. It could be done more softly with a deprecation.
>
> Cleanups at the level of Object are particularly valuable.

It needs to be done in a way that is sustainable. That means with a code
rewrite rule. Deprecations are not enough. The number of people who can
migrate forwards older code is very small, especially as we are missing
crucial parts of design discussion that took place on slack and were not
copied to mail.

When I created my Morphic screencasts I had to look back to mailing list
discussions from 10 years ago and had to run ancient squeak images to gain
an understanding of how things were supposed to work and how they changed.

Cleanups at this low level need to be done with rewrite rules (and tests)

Stephan

Esteban A. Maringolo

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

2018-02-23 14:50 GMT-03:00 Stephan Eggermont <[hidden email]>:
> Sven Van Caekenberghe <[hidden email]> wrote:

>> Cleanups at the level of Object are particularly valuable.
>
> It needs to be done in a way that is sustainable. That means with a code
> rewrite rule. Deprecations are not enough. The number of people who can
> migrate forwards older code is very small, especially as we are missing
> crucial parts of design discussion that took place on slack and were not
> copied to mail.

Why not both?

With a noisy enough deprecation warning and a handy rewrite rules
script it would ease the transition.

AFAIR the procedure was to mark as deprecated in one release and
remove completely in the next one.

Best regards!

Esteban A. Maringolo

Sean P. DeNigris

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

Administrator

Esteban A. Maringolo wrote
>> That means with a code rewrite rule. Deprecations are not enough.
> Why not both?

It seems like you're both saying the same thing, no? Isn't this all
accomplished via:
self
deprecated: 'Renamed to #action because now accepts any valuable as an
action (e.g. aBlock).'
on: '10/24/2017'
in: #Pharo61
transformWith: '`@receiver selector'
-> '`@receiver action'.

Or are you saying there should be a collection of rewrite rules even after
the method is totally removed so one can bring a very old project up to the
newest APIs?

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Cheers,
Sean

Stephan Eggermont-3

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

Sean P. DeNigris <[hidden email]> wrote:
> Or are you saying there should be a collection of rewrite rules even after
> the method is totally removed so one can bring a very old project up to the
> newest APIs?

Making sure the code works in each intermediate version of Pharo is
increasingly unattractive. It also requires indefinite support of all the
old pharo versions. A collection of separate rewrite rules looks to me like
the right thing to both explain changes and speed up migrations.

Stephan

Stephane Ducasse-3

Re: #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

Stephan

Can you stop ranting for ranting and be positive thinking?
Don't you think that are ARE PAYING ATTENTION!!!
We will NOT END UP looking like some other systems!

If you want to help here is a concrete proposal (we want to do it but
we are busy doing bullshit works like
reviewing fix and fixing typos around).
- Gather all the deprecated methods in the past Pharo versions
starting with Pharo 60.
- add Transform rule when posible
- package them so that people can load it and get helped during their migration

EASY NO?

sorry but I have something to hear that such kind of emails.

Stef

On Fri, Feb 23, 2018 at 8:20 PM, Stephan Eggermont <[hidden email]> wrote:

> Sean P. DeNigris <[hidden email]> wrote:
>> Or are you saying there should be a collection of rewrite rules even after
>> the method is totally removed so one can bring a very old project up to the
>> newest APIs?
>
> Making sure the code works in each intermediate version of Pharo is
> increasingly unattractive. It also requires indefinite support of all the
> old pharo versions. A collection of separate rewrite rules looks to me like
> the right thing to both explain changes and speed up migrations.
>
> Stephan
>
>