Smalltalk › Pharo › Pharo Smalltalk Developers

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

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 4 messages Options
Ben Coman
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Ben Coman


On Fri, 30 Aug 2019 at 15: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?

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

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

Stéphane Ducasse
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 <[hidden email]> wrote:



On Fri, 30 Aug 2019 at 15: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?

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

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

Christopher Fuhrman-4
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-td4880925.html that mentions a Pharo implementation of the principle.

On Fri, 30 Aug 2019 at 07:19, Stéphane Ducasse <[hidden email]> 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 <[hidden email]> wrote:



On Fri, 30 Aug 2019 at 15: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?

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
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
Nicolas Cellier
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Nicolas Cellier
Personnally I sometimes want to break the contracts because I know that I don't need them and can optimize some performance-critical operations.

A good example is Fraction.
The invariants are:
    numerator isInteger and: [denominator isInteger and: [
    denominator strictlyPositive and: [numerator isZero not and: [(numerator gcd: denominator) = 1]]]]

Remark: we can see that there is an order in the invariants, we would not want to test (numerator gcd: denominator) = 1 before knowing they are integer...

Normal usage is (Fraction numerator: n denominator: d) reduced, unless sender has the last two invariants in preconditions, in which case it can omit sending reduced.
But when parsing Float, we write (Fraction numerator: n denominator: d) asFloat, even if the last invariant does not apply, because asFloat will perform some form of reduction either directly in floating point arithmetic, or via a quo: operation to keep only significand part, and because the last but one invariant is already in pre condition of sender.

So a correct specification would be to apply the last two invariant to every Fraction method, but two exceptions: reduced (obviously) and asFloat.

That would be a great way to specify the subtle arrangement. Also I was thinking that reduced could be entirely omitted when the contract is known to be fullfilled... That's a great deal of the optimizations that we are performing manually (like Fraction>>#squared etc...) but if a system could find that by induction (given the declarative pre/post contracts) it could probably find many more (I imagine when having type information like in Sista inlining phase).

Le ven. 30 août 2019 à 15:18, Christopher Fuhrman <[hidden email]> a écrit :
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-td4880925.html that mentions a Pharo implementation of the principle.

On Fri, 30 Aug 2019 at 07:19, Stéphane Ducasse <[hidden email]> 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 <[hidden email]> wrote:



On Fri, 30 Aug 2019 at 15: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?

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
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
Free forum by Nabble Edit this page