SequenceableCollection>>#allButFirst: inconsistence across subclasses

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

SequenceableCollection>>#allButFirst: inconsistence across subclasses

Julien
Hello,


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
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40

Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

CyrilFerlicot


On Fri 30 Aug 2019 at 09:34, Julien <[hidden email]> wrote:
Hello,


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
Numéro de téléphone: +333 59 35 86 40

--
Cyril Ferlicot
https://ferlicot.fr
Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Herby Vojčík
In reply to this post by Julien
On 30. 8. 2019 11:56, Ben Coman wrote:

>
>
> On Fri, 30 Aug 2019 at 15:34, Julien <[hidden email]
> <mailto:[hidden email]>> 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


Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Kasper Osterbye
In reply to this post by CyrilFerlicot
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 ([hidden email]) wrote:



On Fri 30 Aug 2019 at 09:34, Julien <[hidden email]> wrote:
Hello,


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
Numéro de téléphone: +333 59 35 86 40

--
Cyril Ferlicot
https://ferlicot.fr
Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Richard O'Keefe
In reply to this post by Julien
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 <[hidden email]> wrote:
Hello,


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
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40

Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> wrote:
Hello,


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
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40

Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Kasper Osterbye
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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 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
Reply | Threaded
Open this post in threaded view
|

Re: 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 [hidden email]
Get a free account at ProtonMail.com

On Sep 3, 2019, at 04:39, Richard O'Keefe <[hidden email]> 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 <[hidden email]> 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 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
Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Marcus Denker-4


> On 4 Sep 2019, at 04:25, John Pfersich <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Sven Van Caekenberghe-2
In reply to this post by John Pfersich
John,

> On 4 Sep 2019, at 04:25, John Pfersich <[hidden email]> wrote:
>
> and gun habits.

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

Thx,

Sven

Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Herby Vojčík
On 4. 9. 2019 10:41, Sven Van Caekenberghe wrote:
> John,
>
>> On 4 Sep 2019, at 04:25, John Pfersich <[hidden email]> wrote:
>>
>> and gun habits.
>
> Please stop normalising guns with such casual remarks.
> Guns have no place in modern society.

Just a reminder the above is not the general opinion.

Be yourself, John!

Herby

> Thx,
>
> Sven

Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Guillermo Polito
In reply to this post by Sven Van Caekenberghe-2


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

+1000

Thanks Sven

>
> Thx,
>
> Sven
>


Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

YannLesage
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 <[hidden email]> a écrit :


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

+1000

Thanks Sven

>
> Thx,
>
> Sven
>


Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Julien


> Le 4 sept. 2019 à 17:12, lesage yann <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Sean P. DeNigris
Administrator
In reply to this post by YannLesage
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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: SequenceableCollection>>#allButFirst: inconsistence across subclasses

Sven Van Caekenberghe-2
In reply to this post by YannLesage


> On 4 Sep 2019, at 17:12, lesage yann <[hidden email]> 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 <[hidden email]> a écrit :
>
>
> > El 4 sept 2019, a las 10:41, Sven Van Caekenberghe <[hidden email]> escribió:
> >
> > John,
> >
> >> On 4 Sep 2019, at 04:25, John Pfersich <[hidden email]> wrote:
> >>
> >> and gun habits.
> >
> > Please stop normalising guns with such casual remarks.
> > Guns have no place in modern society.
>
> +1000
>
> Thanks Sven
>
> >
> > Thx,
> >
> > Sven
> >
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Ssilence does not mean agreement

jgfoster

> On Sep 4, 2019, at 10:22 AM, Sven Van Caekenberghe <[hidden email]> wrote:
> I felt compelled to react since not doing so would mean I silently agree.

Please try to get over your compulsion.

Reply | Threaded
Open this post in threaded view
|

Re: Ssilence does not mean agreement

Sven Van Caekenberghe-2
James,

OFF LIST

> On 4 Sep 2019, at 19:50, James Foster <[hidden email]> wrote:
>
>
>> On Sep 4, 2019, at 10:22 AM, Sven Van Caekenberghe <[hidden email]> wrote:
>> I felt compelled to react since not doing so would mean I silently agree.
>
> Please try to get over your compulsion.

If nobody talks casually about guns as if they are a normal part of life on this list I will have no problem doing so.

Sven
 
Reply | Threaded
Open this post in threaded view
|

Re: Ssilence does not mean agreement

Herby Vojčík
On 4. 9. 2019 20:10, Sven Van Caekenberghe wrote:
> If nobody talks casually about guns as if they are a normal part of life on this list I will have no problem doing so.

You are not director here.

Get over your compulsion. If unable yourself, seek medical help.

Herby

> Sven

12