Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Sven Van Caekenberghe]

> On 4 Sep 2019, at 17:12, lesage yann  wrote:
> 
> Hi,
> Can you open an another thread to talk about guns and stay on inconsistency 
> issue here ?
> Thanks

You are right and I am sorry, the Pharo mailing lists should only be used for 
technical and community discussions.

It was a catch 22 however: I felt compelled to react since not doing so would 
mean I silently agree (with talking casually about guns and doing so here).

> Le mer. 4 sept. 2019 à 16:37, Guillermo Polito  a 
> écrit :
> 
> 
> > El 4 sept 2019, a las 10:41, Sven Van Caekenberghe  escribió:
> > 
> > John,
> > 
> >> On 4 Sep 2019, at 04:25, John Pfersich  wrote:
> >> 
> >> and gun habits.
> > 
> > Please stop normalising guns with such casual remarks.
> > Guns have no place in modern society.
> 
> +1000
> 
> Thanks Sven
> 
> > 
> > Thx,
> > 
> > Sven
> > 
> 
> 

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Sean P. DeNigris]

YannLesage wrote
> Can you open an another thread to talk about guns and stay on
> inconsistency
> issue here ?

I fear better yet keep emotional non-programming-related issues elsewhere
entirely. Nothing can be accomplished here except to weaken and distract our
community.



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

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Julien]

> Le 4 sept. 2019 à 17:12, lesage yann  a écrit :
> 
> Hi,
> Can you open an another thread to talk about guns and stay on inconsistency 
> issue here ?
> Thanks

Agree, but I think it is already too late, the focus is lost now...

Regards,

Julien

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[lesage yann]

Hi,
Can you open an another thread to talk about guns and stay on inconsistency
issue here ?
Thanks

Le mer. 4 sept. 2019 à 16:37, Guillermo Polito 
a écrit :

>
>
> > El 4 sept 2019, a las 10:41, Sven Van Caekenberghe 
> escribió:
> >
> > John,
> >
> >> On 4 Sep 2019, at 04:25, John Pfersich  wrote:
> >>
> >> and gun habits.
> >
> > Please stop normalising guns with such casual remarks.
> > Guns have no place in modern society.
>
> +1000
>
> Thanks Sven
>
> >
> > Thx,
> >
> > Sven
> >
>
>
>

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Sven Van Caekenberghe]

John,

> On 4 Sep 2019, at 04:25, John Pfersich  wrote:
> 
> and gun habits.

Please stop normalising guns with such casual remarks.
Guns have no place in modern society.

Thx,

Sven

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Marcus Denker]

> On 4 Sep 2019, at 04:25, John Pfersich  wrote:
> 
> +100. Smalltalk for me is a hobby which comes after the music (guitar and 
> keyboards) and gun habits. I used to code in Smalltalk professionally, but 
> haven’t had a paid job in 26 years. I used to produce code for Squeak back in 
> the early 2000’s, but stopped because my code never made it into the image 
> that I know of. I just code for myself now.

This was a huge problem with Squeak… at first I thought that it could be fixed 
in Squeak and I spend *a lot* of energy to get to a setup where not every fix 
and improvement is ignored.

In the end one of the reasons why I left Squeak.


Marcus

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[John Pfersich]

+100. Smalltalk for me is a hobby which comes after the music (guitar and 
keyboards) and gun habits. I used to code in Smalltalk professionally, but 
haven’t had a paid job in 26 years. I used to produce code for Squeak back in 
the early 2000’s, but stopped because my code never made it into the image that 
I know of. I just code for myself now.

//
For encrypted mail use jgpfers...@protonmail.com
Get a free account at ProtonMail.com
Web: www.objectnets.net and www.objectnets.org

> On Sep 3, 2019, at 04:39, Richard O'Keefe  wrote:
> 
> Ad 1.
>To cut a long story short,
>the ANSI Smalltalk standard is the nearest thing we have to a clear 
> specification
>of the nearest thing we have to a consensus.
>One of the reasons that Smalltalk gets less use than many of us would like
>is that it can be extremely unpleasant trying to port from one dialect of
>Smalltalk to another, so you have to commit to a dialect.
>And dialects of Smalltalk have an unpleasant habit of disappearing.
>I really liked Ambrai.  What was I to do with my Ambrai code when
>Ambrai disappeared? 
>I have never met a better-looking Smalltalk than Dolphin.
>ObjectArts stopped selling Dolphin a year or two ago, and open sourced it.
>Today the ObjectArts website has an expired certificate,
>pages have the date 2016 on them,
>and the GitHub link points to a GitHub site containing an Amber fork
>but no Dolphin.
>Imagine my relief at discovering that Dolphin *is* still being maintained,
>it's just not where ObjectArts said it was.  But I am worried about
>whether I should bother with it any more.
>Then there's ST/X.
>...
> 
>Code written for C99 is still useful.
>I have four different C compilers and I don't have to care which one I use.
> 
>Code written for Fortran95 is still useful (and yes I know about Fortran 
> 2018).
>I have two different Fortran compilers; the one that does the best job 
> handles
>Fortran 2003 but not 2008 or 2018, and as long as I stick to 2003 I don't 
> have
>to care which I use.
> 
>The Common Lisp standard came out in 1994 and the HyperSpec is still useful
>to me for writing Lisp today.
>My copy of Common Lisp the Language, 2nd edition, is still useful to me.
> 
> Ad 2.
>In the Pharo 7.0 sources there are on the order of 600 senders of 
> #signal[:]
>-- exceptions and semaphores both use #signal so this is approximate --
>and on the order of 1000 senders of #error:, which really should be
>exceptions.  (It is surprisingly hard to make this change.)  The newer
>components use exceptions a lot more than the old ones.
>Of course some exceptions (like subscript out of bounds) are raised
>inside primitives, which Ctrl-N doesn't show you.
> 
>One quite strange thing about the ANSI Smalltalk standard is that it
>introduced an elaborate exception-handling system into the language
>-- much more complicated than C++ or Java or Ada -- but introduced
>almost no standard exceptions that a portable program could catch.
>Let's take one consequence of this.
>What does
>   (OrderedCollection withAll: #[3 1 4 1 5 9]) copyFrom: 2.5 to: 4.2
>do?
>My Smalltalk: currently reports 'bad start' coming from the call to
>#copyFrom:to: with culprit 2.5.
>This is going to be an IndexError some day; cleaning
>up the code to use well-chosen exceptions is a mammoth task.
> 
>Squeak: 'Array called #basicNew: with invalid argument 2.7'
>Of course there is no 2.7 in our code...
> 
>Pharo: 'PrimitiveFailed: primitive #basicNew: in Array class failed'
> 
>VW: 'Unhandled exception: This message needs a positive integer argument'
>appearing to come from OrderedCollection>>new:
> 
>VisualAge Smalltalk: drops you into a debugger with no actual explanation;
>the only number in sight is 2.7, which is not one of the numbers we 
> provided.
> 
>GNU Smalltalk: 'Object: 1 error: The program attempted to divide a number 
> by zero'.
>I kid you not.
> 
>Exceptions could be useful IF you knew what to catch.
> 
>Just for grins, sending #copyFrom:to: to an OrderedCollection with a start
>or stop value out of range raises an ExCLDTIndexOutOfRange exception but
>sending it to an Array with the same contents does not.
> 
> Ad 3.
>allButFirst: n ^self copyFrom: n+1 to: self size
>and then ask what #copyFrom:to: should do.
> 
> This is actually one tiny symptom of a pervasive issue in Smalltalk.
> When commercial Smalltalks are riddled with not-quite-working and/or
> not-self-consistent stuff in basic classes, what can we expect from
> an open source project, unless someone is prepared to donate serious
> money for a cleanup?
> 
> 
>> On Tue, 3 Sep 2019 at 04:01, Kasper Østerbye  
>> wrote:
>> This is actually an intersting discussion. There are several levels to it.
>> 
>> 1. Should Pharo be compatible 

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Richard O'Keefe]

Ad 1.
   To cut a long story short,
   the ANSI Smalltalk standard is the nearest thing we have to a clear
specification
   of the nearest thing we have to a consensus.
   One of the reasons that Smalltalk gets less use than many of us would
like
   is that it can be extremely unpleasant trying to port from one dialect of
   Smalltalk to another, so you have to commit to a dialect.
   And dialects of Smalltalk have an unpleasant habit of disappearing.
   I really liked Ambrai.  What was I to do with my Ambrai code when
   Ambrai disappeared?
   I have never met a better-looking Smalltalk than Dolphin.
   ObjectArts stopped selling Dolphin a year or two ago, and open sourced
it.
   Today the ObjectArts website has an expired certificate,
   pages have the date 2016 on them,
   and the GitHub link points to a GitHub site containing an Amber fork
   but no Dolphin.
   Imagine my relief at discovering that Dolphin *is* still being
maintained,
   it's just not where ObjectArts said it was.  But I am worried about
   whether I should bother with it any more.
   Then there's ST/X.
   ...

   Code written for C99 is still useful.
   I have four different C compilers and I don't have to care which one I
use.

   Code written for Fortran95 is still useful (and yes I know about Fortran
2018).
   I have two different Fortran compilers; the one that does the best job
handles
   Fortran 2003 but not 2008 or 2018, and as long as I stick to 2003 I
don't have
   to care which I use.

   The Common Lisp standard came out in 1994 and the HyperSpec is still
useful
   to me for writing Lisp today.
   My copy of Common Lisp the Language, 2nd edition, is still useful to me.

Ad 2.
   In the Pharo 7.0 sources there are on the order of 600 senders of
#signal[:]
   -- exceptions and semaphores both use #signal so this is approximate --
   and on the order of 1000 senders of #error:, which really should be
   exceptions.  (It is surprisingly hard to make this change.)  The newer
   components use exceptions a lot more than the old ones.
   Of course some exceptions (like subscript out of bounds) are raised
   inside primitives, which Ctrl-N doesn't show you.

   One quite strange thing about the ANSI Smalltalk standard is that it
   introduced an elaborate exception-handling system into the language
   -- much more complicated than C++ or Java or Ada -- but introduced
   almost no standard exceptions that a portable program could catch.
   Let's take one consequence of this.
   What does
  (OrderedCollection withAll: #[3 1 4 1 5 9]) copyFrom: 2.5 to: 4.2
   do?
   My Smalltalk: currently reports 'bad start' coming from the call to
   #copyFrom:to: with culprit 2.5.
   This is going to be an IndexError some day; cleaning
   up the code to use well-chosen exceptions is a mammoth task.

   Squeak: 'Array called #basicNew: with invalid argument 2.7'
   Of course there is no 2.7 in our code...

   Pharo: 'PrimitiveFailed: primitive #basicNew: in Array class failed'

   VW: 'Unhandled exception: This message needs a positive integer argument'
   appearing to come from OrderedCollection>>new:

   VisualAge Smalltalk: drops you into a debugger with no actual
explanation;
   the only number in sight is 2.7, which is not one of the numbers we
provided.

   GNU Smalltalk: 'Object: 1 error: The program attempted to divide a
number by zero'.
   I kid you not.

   Exceptions could be useful IF you knew what to catch.

   Just for grins, sending #copyFrom:to: to an OrderedCollection with a
start
   or stop value out of range raises an ExCLDTIndexOutOfRange exception but
   sending it to an Array with the same contents does not.

Ad 3.
   allButFirst: n ^self copyFrom: n+1 to: self size
   and then ask what #copyFrom:to: should do.

This is actually one tiny symptom of a pervasive issue in Smalltalk.
When commercial Smalltalks are riddled with not-quite-working and/or
not-self-consistent stuff in basic classes, what can we expect from
an open source project, unless someone is prepared to donate serious
money for a cleanup?


On Tue, 3 Sep 2019 at 04:01, Kasper Østerbye 
wrote:

> This is actually an intersting discussion. There are several levels to it.
>
> 1. Should Pharo be compatible with a standard from 1998?
> 2. What is the general view on using exceptions in Pharo?
> 3. What should allButFirst: do?
>
> Ad 1) I am relatively new to Pharo, If backwards compatibility is
> important, it should adhere to the standard and the spirit of the standard.
> If we want a different semantics in some areas, it seems like new methods
> are needed, with names which is not confused with existing standard.
>
> Ad 2) I am so new to Pharo I do not even know how efficient (or expensive)
> exceptions are in Pharo. In most programming languages they are expensive,
> and should not be used as an alternative to an if statement. My views on
> exceptions are very influenced by Bertrand Meyer, which lead me to the view
> that a) Asking for the all but the first 

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Kasper Østerbye]

This is actually an intersting discussion. There are several levels to it.

1. Should Pharo be compatible with a standard from 1998?
2. What is the general view on using exceptions in Pharo?
3. What should allButFirst: do?

Ad 1) I am relatively new to Pharo, If backwards compatibility is
important, it should adhere to the standard and the spirit of the standard.
If we want a different semantics in some areas, it seems like new methods
are needed, with names which is not confused with existing standard.

Ad 2) I am so new to Pharo I do not even know how efficient (or expensive)
exceptions are in Pharo. In most programming languages they are expensive,
and should not be used as an alternative to an if statement. My views on
exceptions are very influenced by Bertrand Meyer, which lead me to the view
that a) Asking for the all but the first three elements of a two element
array is most likely a broken pre-condition. Hence an error. b) As it is
the clients responsibility to ensure precondition, we might as well help
the client of the collection by offering an other method with a different
pre-condition.

Ad 3. Should follow from the first two :-)

Best,

Kasper

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Richard O'Keefe]

I didn't join all the dots.
My point is that [all] but {first,last} have simple definitions in terms
of #copyFrom:to: and that if you want to make them accept oversize counts,
you either have to change the definition of #copyFrom:to: (bad idea) or
cut these methods loose from #copyFrom:to: and define them in terms of
something else.

I should also explain that there are at least four plausible
definitions:
  (1) 'the first n elements of x' is exactly n elements long
  (current Squeak and Pharo 8)
  (2) 'the first n elements of x' is (x size min: n) elements long
  (3) 'the first n elements of x' is exactly |n| elements long;
  it's the first n if n >= 0 or the last |n| if n <= 0.
  (34 'the first n elements of x' is exactly n elements long
  and if x size < n the last n - x size elements are the
  default value for n (nil for objects, zero for numbers,
  blank for characters).

Number (3) is the original APL\360 definition found in the 1968
manual from IBM.  While the sign dependence wrecks the lovely
v = (n .take v) , (n .drop v)
property, APL wants to let you pick *any* corner of an array
with *any* number of subscripts in a single operator.

Number (4) is the definition found in the APL standard (the
1993 draft, anyway).

My resolution was to say that #first: (#last:) and #take: are
DIFFERENT operations, where
   take: n
  ^n positive
 ifTrue:  [self first: (self size min: n)]
 ifFalse: [self last:  (self size min: n negated)]
   drop: n
  ^n positive
 ifTrue:  [self allButFirst: (self size min: n)]
 ifFalse: [self allButLast:  (self size min: n negated)]

They are different because they have different preconditions and
postconditions.  Why did I not follow APL more closely?  Because
I tried hard to define a #defaultElement for sequences and failed
to come up with anything coherent.  Also, APL is just as happy
with floating point counts as with integer ones, provided they
are close enough to integral.

I should also point out that Pharo 8 does not respect the ANSI
semantics of #copyFrom:to:.  Example:
   'abc' copyFrom: 6 to: 0
should, according to the common specification, answer ''.
The result is instead a primitive failure in #basicNew:, of
all things.

On Mon, 2 Sep 2019 at 20:37, Richard O'Keefe  wrote:

> Here's what I think.
>
> copyFrom: start to: stop
>   " ANSI Smalltalk section 5.7.8.7, reorganised a bit.
>
> Answer a new collection containing all of the elements of the
> receiver between the indices start and stop inclusive in their
> original order.  The element at index start in the receiver is
> at index 1 in the result, the element at index start+1 is at
> index 2, etc.  If stop < start, the new collection is emptyy.
> Otherwise, the size of the new collection is the maximum of
> (stop - start + 1) and 0.  The parameters start and stop must
> be positive integers.
> Errors
> If stop >= start and (start < 1 or start > the receiver's size).
> If stop >= start and (stop < 1 or stop > the receiver's size).
>   "
> ((start isKindOf: Integer) and: [start positive])
>   ifFalse: [start error: 'not a positive integer'].
> ((stop  isKindOf: Integer) and: [stop  positive])
>   ifFalse: [stop  error: 'not a positive integer'].
> ^stop < start
>ifTrue:  [self copyEmpty]
>  ifFalse: [(start between: 1 and: self size)
>ifFalse: [start error: 'index out of range'].
>  (stop  between: 1 and: self size)
>ifFalse: [stop  error: 'index out of range'].
>  self from: start to: stop collect: [:each | each]]
>
> allButFirst
> ^self allButFirst: 1
>
> allButFirst: count
> ^self copyFrom: count + 1 to: self size
>
> allButLast
> ^self allButLast: 1
>
> allButLast: count
> ^self copyFrom: 1 to: self size - count
>
> first: count
> "(x first: n) , (x allButFirst: n) = x and: [(x first: n) size = n]"
> ^self copyFrom: 1 to: count
>
> last: count
> "(x allButLast: n) , (x last: n) = x and: [(x last: n) size = n]"
> ^self copyFrom: self size - count to: self size
>
>
> See the comments in #first: and #last: ?
> In order to program effectively, I need operations with *simple*
> specifications.
> "seq first: n  returns the first n elements of seq or it's an error"
> "seq last: n   returns the last  n elements of seq or it's an error"
> This has the virtue of making these pretty redundant operations fully
> consistent with #copyFrom:to:
>
>
>
> On Fri, 30 Aug 2019 at 19:34, Julien  wrote:
>
>> Hello,
>>
>> I opened that issue: https://github.com/pharo-project/pharo/issues/4442
>>
>> And I think to fix it we need to actually discuss about what we want.
>>
>> #allButFirst: behaves differently depending on the actual type of
>> sequenceable collection when argument is greater than collection size.
>>
>> For instance:
>>
>> #(1 2) allButFirst: 3.  "PrimitiveFailed signaled"
>> 

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Richard O'Keefe]

Here's what I think.

copyFrom: start to: stop
  " ANSI Smalltalk section 5.7.8.7, reorganised a bit.

Answer a new collection containing all of the elements of the
receiver between the indices start and stop inclusive in their
original order.  The element at index start in the receiver is
at index 1 in the result, the element at index start+1 is at
index 2, etc.  If stop < start, the new collection is emptyy.
Otherwise, the size of the new collection is the maximum of
(stop - start + 1) and 0.  The parameters start and stop must
be positive integers.
Errors
If stop >= start and (start < 1 or start > the receiver's size).
If stop >= start and (stop < 1 or stop > the receiver's size).
  "
((start isKindOf: Integer) and: [start positive])
  ifFalse: [start error: 'not a positive integer'].
((stop  isKindOf: Integer) and: [stop  positive])
  ifFalse: [stop  error: 'not a positive integer'].
^stop < start
   ifTrue:  [self copyEmpty]
 ifFalse: [(start between: 1 and: self size)
   ifFalse: [start error: 'index out of range'].
 (stop  between: 1 and: self size)
   ifFalse: [stop  error: 'index out of range'].
 self from: start to: stop collect: [:each | each]]

allButFirst
^self allButFirst: 1

allButFirst: count
^self copyFrom: count + 1 to: self size

allButLast
^self allButLast: 1

allButLast: count
^self copyFrom: 1 to: self size - count

first: count
"(x first: n) , (x allButFirst: n) = x and: [(x first: n) size = n]"
^self copyFrom: 1 to: count

last: count
"(x allButLast: n) , (x last: n) = x and: [(x last: n) size = n]"
^self copyFrom: self size - count to: self size


See the comments in #first: and #last: ?
In order to program effectively, I need operations with *simple*
specifications.
"seq first: n  returns the first n elements of seq or it's an error"
"seq last: n   returns the last  n elements of seq or it's an error"
This has the virtue of making these pretty redundant operations fully
consistent with #copyFrom:to:



On Fri, 30 Aug 2019 at 19:34, Julien  wrote:

> Hello,
>
> I opened that issue: https://github.com/pharo-project/pharo/issues/4442
>
> And I think to fix it we need to actually discuss about what we want.
>
> #allButFirst: behaves differently depending on the actual type of
> sequenceable collection when argument is greater than collection size.
>
> For instance:
>
> #(1 2) allButFirst: 3.  "PrimitiveFailed signaled"
> (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled"
> (OrderedCollection with: 1 with: 2) allButFirst: 3.  "an
> OrderedCollection() »
>
> The question is then, who is right?
>
> Should #allButFirst: with an argument greater than the collection size
> raise an error
>
> Or
>
> Should #allButFirst: with an argument greater than the collection size
> returns an empty collection ?
>
> I asked a few people about it @ ESUG and it appears that the expected
> behaviour from #allButFirst: is not the same to all people.
>
> We need to decide so we improve consistence of collections.
>
> And then, we need to document that with a test :-).
>
> Cheers.
>
> Julien
>
> ---
> Julien Delplanque
> Doctorant à l’Université de Lille
> http://juliendelplanque.be/phd.html
> Equipe Rmod, Inria
> Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
> Numéro de téléphone: +333 59 35 86 40
>
>

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Kasper Østerbye]

I always like to find a way not to make the choice.

#(1 2) allButFirst: 3 ifInsufficient: […]

allButFirst: N
^self allButFirst: N ifInsufficent: [ “fight about this"].

— Kasper


On 30 August 2019 at 12.28.14, Cyril Ferlicot (cyril.ferli...@gmail.com)
wrote:



On Fri 30 Aug 2019 at 09:34, Julien  wrote:

> Hello,
>
> I opened that issue: https://github.com/pharo-project/pharo/issues/4442
>
> And I think to fix it we need to actually discuss about what we want.
>
> #allButFirst: behaves differently depending on the actual type of
> sequenceable collection when argument is greater than collection size.
>
> For instance:
>
> #(1 2) allButFirst: 3.  "PrimitiveFailed signaled"
> (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled"
> (OrderedCollection with: 1 with: 2) allButFirst: 3.  "an
> OrderedCollection() »
>
> The question is then, who is right?
>
> Should #allButFirst: with an argument greater than the collection size
> raise an error
>
> Or
>
> Should #allButFirst: with an argument greater than the collection size
> returns an empty collection ?
>
> I asked a few people about it @ ESUG and it appears that the expected
> behaviour from #allButFirst: is not the same to all people.
>
> We need to decide so we improve consistence of collections.
>
> And then, we need to document that with a test :-).
>

Hi,

I was one of the person who discussed this with Julien at ESUG and IMO it
should launch an error.

While working on complexe models, errors in such cases are really really
really helpful to find bugs. Errors such as SubscriptOutOfBound or NotFound
help me a lot to find bugs and sometimes without this kind of methods it
could have take me days to find the problem (and it’s only in the case I
know there is a bug).


> Cheers.
>
> Julien
>
> ---
> Julien Delplanque
> Doctorant à l’Université de Lille
> http://juliendelplanque.be/phd.html
> Equipe Rmod, Inria
> Bâtiment B 40, Avenue Halley 59650
> 
>  Villeneuve
> 
>  d'Ascq
> 
> Numéro de téléphone: +333 59 35 86 40
>
> --
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Herby Vojčík]

On 30. 8. 2019 11:56, Ben Coman wrote:



On Fri, 30 Aug 2019 at 15:34, Julien > wrote:


Hello,

I opened that issue: https://github.com/pharo-project/pharo/issues/4442

And I think to fix it we need to actually discuss about what we want.

#allButFirst: behaves differently depending on the actual type of
sequenceable collection when argument is greater than collection size.

For instance:

#(1 2) allButFirst: 3.  "PrimitiveFailed signaled"
(LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled"
(OrderedCollection with: 1 with: 2) allButFirst: 3.  "an
OrderedCollection() »

The question is then, who is right?


Its worthwhile to at least survey other Smalltalks.
For Visualworks...
       #(1 2) allButFirst: 3.  "==> #()"
       (OrderedCollection with: 1 with: 2) allButFirst: 3.   "==> 
OrderedCollection ()"
       (LinkedList with: Link new with: Link new ) allButFirst: 3.  
"raises an error Subscription out of bounds error"

and also...
       (LinkedList with: Link new with: Link new ) allButFirst: 2.  
"raises an error Subscription out of bounds error"


I feel that proceeding-without-iterating is nicer than 
showing-an-application-error.
It provides the opportunity to not-check the number elements or wrapping 
error handling around it - i.e. less code if its not important.


That's what I think as well.

If its important not to exceed the number of elements, then that check 
can be explicitly coded.


cheers -ben

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Cyril Ferlicot]

On Fri 30 Aug 2019 at 09:34, Julien  wrote:

> Hello,
>
> I opened that issue: https://github.com/pharo-project/pharo/issues/4442
>
> And I think to fix it we need to actually discuss about what we want.
>
> #allButFirst: behaves differently depending on the actual type of
> sequenceable collection when argument is greater than collection size.
>
> For instance:
>
> #(1 2) allButFirst: 3.  "PrimitiveFailed signaled"
> (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled"
> (OrderedCollection with: 1 with: 2) allButFirst: 3.  "an
> OrderedCollection() »
>
> The question is then, who is right?
>
> Should #allButFirst: with an argument greater than the collection size
> raise an error
>
> Or
>
> Should #allButFirst: with an argument greater than the collection size
> returns an empty collection ?
>
> I asked a few people about it @ ESUG and it appears that the expected
> behaviour from #allButFirst: is not the same to all people.
>
> We need to decide so we improve consistence of collections.
>
> And then, we need to document that with a test :-).
>

Hi,

I was one of the person who discussed this with Julien at ESUG and IMO it
should launch an error.

While working on complexe models, errors in such cases are really really
really helpful to find bugs. Errors such as SubscriptOutOfBound or NotFound
help me a lot to find bugs and sometimes without this kind of methods it
could have take me days to find the problem (and it’s only in the case I
know there is a bug).


> Cheers.
>
> Julien
>
> ---
> Julien Delplanque
> Doctorant à l’Université de Lille
> http://juliendelplanque.be/phd.html
> Equipe Rmod, Inria
> Bâtiment B 40, Avenue Halley 59650
> 
>  Villeneuve
> 
>  d'Ascq
> 
> Numéro de téléphone: +333 59 35 86 40
>
> --
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

[Ben Coman]

On Fri, 30 Aug 2019 at 15:34, Julien  wrote:

> Hello,
>
> I opened that issue: https://github.com/pharo-project/pharo/issues/4442
>
> And I think to fix it we need to actually discuss about what we want.
>
> #allButFirst: behaves differently depending on the actual type of
> sequenceable collection when argument is greater than collection size.
>
> For instance:
>
> #(1 2) allButFirst: 3.  "PrimitiveFailed signaled"
> (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled"
> (OrderedCollection with: 1 with: 2) allButFirst: 3.  "an
> OrderedCollection() »
>
> The question is then, who is right?
>

Its worthwhile to at least survey other Smalltalks.
For Visualworks...
  #(1 2) allButFirst: 3.  "==> #()"
  (OrderedCollection with: 1 with: 2) allButFirst: 3.   "==>
OrderedCollection ()"
  (LinkedList with: Link new with: Link new ) allButFirst: 3.  "raises
an error Subscription out of bounds error"
and also...
  (LinkedList with: Link new with: Link new ) allButFirst: 2.  "raises
an error Subscription out of bounds error"

I feel that proceeding-without-iterating is nicer than
showing-an-application-error.
It provides the opportunity to not-check the number elements or wrapping
error handling around it - i.e. less code if its not important.
If its important not to exceed the number of elements, then that check can
be explicitly coded.

cheers -ben