++++++999^1000 :)

On Fri, Feb 23, 2018 at 7:32 AM, Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> Thanks Sven
> I thought that suddenly I was an idiot.
>
>
> On Thu, Feb 22, 2018 at 11:47 AM, Sven Van Caekenberghe <s...@stfx.eu>
> wrote:
> >
> >
> >> On 22 Feb 2018, at 10:41, Clément Bera <bera.clem...@gmail.com> wrote:
> >>
> >>
> >>
> >> On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <
> stepharo.s...@gmail.com> 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 <bera.clem...@gmail.com>
> 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 <
> smallt...@stefan-marr.de>
> >> > 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
<http://www.cnrs.fr>*


*Web:* *http://guillep.github.io* <http://guillep.github.io>

*Phone: *+33 06 52 70 66 13

Reply via email to