Is this not the classic problem solved by design by contract (as in Eiffel)? Deciding who must check for errors (sender or receiver) and specifying it formally (the contract) is more important rather than who SHOULD check. I found http://forum.world.st/Run-time-checking-with-design-by-contract-assertions-t... that mentions a Pharo implementation of the principle. On Fri, 30 Aug 2019 at 07:19, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
over breakfast Santiago was suggesting that we have allButFirst:ifOutOfBounds:
and he said that having an exception is important because you want to know if we get data data or not. And in that case the client will have to check all the time.
Stef
On 30 Aug 2019, at 11:56, Ben Coman <btc@openinworld.com> wrote:
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
-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France
-- Christopher Fuhrman, P.Eng., PhD *Professeur au Département de génie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supérieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'Université du Québec*