SequenceableCollection>>#allButFirst: inconsistence across subclasses
Hello, I opened that issue: https://github.com/pharo-project/pharo/issues/4442 <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
On Fri, 30 Aug 2019 at 15:34, Julien <julien.delplanque@inria.fr> 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
On 30. 8. 2019 11:56, Ben Coman wrote:
On Fri, 30 Aug 2019 at 15:34, Julien <julien.delplanque@inria.fr <mailto:julien.delplanque@inria.fr>> 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
On Fri 30 Aug 2019 at 09:34, Julien <julien.delplanque@inria.fr> 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 <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> Villeneuve <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> d'Ascq <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> Numéro de téléphone: +333 59 35 86 40
-- Cyril Ferlicot https://ferlicot.fr
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.ferlicot@gmail.com) wrote: On Fri 30 Aug 2019 at 09:34, Julien <julien.delplanque@inria.fr> 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 <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> Villeneuve <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> d'Ascq <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> Numéro de téléphone: +333 59 35 86 40
-- Cyril Ferlicot https://ferlicot.fr
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 <julien.delplanque@inria.fr> 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
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 <raoknz@gmail.com> 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 <julien.delplanque@inria.fr> 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
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
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 <kasper.osterbye@gmail.com> 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
+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 jgpfersich@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 <raoknz@gmail.com> 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 <kasper.osterbye@gmail.com> 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
On 4 Sep 2019, at 04:25, John Pfersich <jpfersich@gmail.com> 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
On 4. 9. 2019 10:41, Sven Van Caekenberghe wrote:
John,
On 4 Sep 2019, at 04:25, John Pfersich <jpfersich@gmail.com> 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
El 4 sept 2019, a las 10:41, Sven Van Caekenberghe <sven@stfx.eu> escribió:
John,
On 4 Sep 2019, at 04:25, John Pfersich <jpfersich@gmail.com> wrote:
and gun habits.
Please stop normalising guns with such casual remarks. Guns have no place in modern society.
+1000 Thanks Sven
Thx,
Sven
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 <guillermopolito@gmail.com> a écrit :
El 4 sept 2019, a las 10:41, Sven Van Caekenberghe <sven@stfx.eu> escribió:
John,
On 4 Sep 2019, at 04:25, John Pfersich <jpfersich@gmail.com> wrote:
and gun habits.
Please stop normalising guns with such casual remarks. Guns have no place in modern society.
+1000
Thanks Sven
Thx,
Sven
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
On 4 Sep 2019, at 17:12, lesage yann <yannlesag@gmail.com> 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 <guillermopolito@gmail.com> a écrit :
El 4 sept 2019, a las 10:41, Sven Van Caekenberghe <sven@stfx.eu> escribió:
John,
On 4 Sep 2019, at 04:25, John Pfersich <jpfersich@gmail.com> wrote:
and gun habits.
Please stop normalising guns with such casual remarks. Guns have no place in modern society.
+1000
Thanks Sven
Thx,
Sven
James, OFF LIST
On 4 Sep 2019, at 19:50, James Foster <Smalltalk@JGFoster.net> wrote:
On Sep 4, 2019, at 10:22 AM, Sven Van Caekenberghe <sven@stfx.eu> 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
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
On 4 Sep 2019, at 20:14, Herby VojÄÃk <herby@mailbox.sk> wrote:
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.
OK, that was mean to go off list, sorry about that. I did not want to continue this thread publicly.
Get over your compulsion. If unable yourself, seek medical help.
This is a silly thing to say, sorry.
Herby
Sven
I refrain from expressing an opinion about any kind of weapon here. I would hope that in a civilised society anyone could casually mention any legal activity they engage in without being subjected to harassment. For what it's worth, I have created a GitHub site for my Smalltalk system, but there's nothing there because my attempt to upload failed. I don't yet know why. When I succeed I'll mention it; it's all open source and anyone will be welcome to use any part of it. On Thu, 5 Sep 2019 at 06:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 4 Sep 2019, at 20:14, Herby VojÄÃk <herby@mailbox.sk> wrote:
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.
OK, that was mean to go off list, sorry about that. I did not want to continue this thread publicly.
Get over your compulsion. If unable yourself, seek medical help.
This is a silly thing to say, sorry.
Herby
Sven
participants (13)
-
Ben Coman -
Cyril Ferlicot -
Guillermo Polito -
Herby VojÄÃk -
James Foster -
John Pfersich -
Julien -
Kasper Ãsterbye -
lesage yann -
Marcus Denker -
Richard O'Keefe -
Sean P. DeNigris -
Sven Van Caekenberghe