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

John Pfersich jpfersich at gmail.com
Tue Sep 3 22:25:44 EDT 2019


+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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20190903/e891d4aa/attachment-0001.html>


More information about the Pharo-users mailing list