[Pharo-project] #reversed and ANSI compatibility
The recent change of renaming #revese to #reversed introduces problems in the Seaside code-base. While I agree that the renaming makes sense, #reverse is part of the ANSI standard and supported by all other Smalltalk implementations. In Seaside we are forced to use it. Could Pharo re-add a not-deprecated delegator of #reverse in SequenceableCollection? I have the opinion that Pharo should follow ANSI if this is easily possible, because this is the only mean of having some minimal kind of compatibility. Lukas -- Lukas Renggli www.lukas-renggli.ch
yes the idea was to have sort sorted reverse reversed for inplace/copy based situation. What ansi specifies for reversed? Stef On May 13, 2010, at 6:47 AM, Lukas Renggli wrote:
The recent change of renaming #revese to #reversed introduces problems in the Seaside code-base.
While I agree that the renaming makes sense, #reverse is part of the ANSI standard and supported by all other Smalltalk implementations. In Seaside we are forced to use it.
Could Pharo re-add a not-deprecated delegator of #reverse in SequenceableCollection? I have the opinion that Pharo should follow ANSI if this is easily possible, because this is the only mean of having some minimal kind of compatibility.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What ansi specifies for reversed?
The problem is that #reverse is deprecated in Pharo 1.1. I didn't look at the implementation of #reversed. If that can be fixed then Seaside 3.0 passes all tests in Pharo 1.1 (after I committed a few changes). ANSI on reverse: 5.7.8.26 Message: reverse Synopsis Answer a collection with the elements of the receiver arranged in reverse order. Definition: <sequenceReadableCollection> Answer a collection conforming to the same protocols as the receiver, but with its elements arranged in reverse order. This operation is equivalent to: 1. Create a new collection which conforms to the same protocols as the receiver; 2. Traverse the elements of the receiver in the order specified by the #reverseDo: message, adding each element of the receiver to the new collection; 3. Answer the new collection. Return Values <RECEIVER> Errors none On 13 May 2010 09:23, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes the idea was to have     sort     sorted     reverse     reversed
for inplace/copy based situation. What ansi specifies for reversed?
Stef
On May 13, 2010, at 6:47 AM, Lukas Renggli wrote:
The recent change of renaming #revese to #reversed introduces problems in the Seaside code-base.
While I agree that the renaming makes sense, #reverse is part of the ANSI standard and supported by all other Smalltalk implementations. In Seaside we are forced to use it.
Could Pharo re-add a not-deprecated delegator of #reverse in SequenceableCollection? I have the opinion that Pharo should follow ANSI if this is easily possible, because this is the only mean of having some minimal kind of compatibility.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
Please integrate this fix: http://code.google.com/p/pharo/issues/detail?id=2428 On 13 May 2010 14:12, Lukas Renggli <renggli@gmail.com> wrote:
What ansi specifies for reversed?
The problem is that #reverse is deprecated in Pharo 1.1. I didn't look at the implementation of #reversed. If that can be fixed then Seaside 3.0 passes all tests in Pharo 1.1 (after I committed a few changes).
ANSI on reverse:
5.7.8.26 Message: Â Â Â reverse
Synopsis
Answer a collection with the elements of the receiver arranged in reverse order. Definition: <sequenceReadableCollection> Answer a collection conforming to the same protocols as the receiver, but with its elements arranged in reverse order. This operation is equivalent to: 1. Create a new collection which conforms to the same protocols as the receiver; 2. Traverse the elements of the receiver in the order specified by the #reverseDo: message, adding each element of the receiver to the new collection; 3. Answer the new collection.
Return Values <RECEIVER>
Errors none
On 13 May 2010 09:23, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes the idea was to have     sort     sorted     reverse     reversed
for inplace/copy based situation. What ansi specifies for reversed?
Stef
On May 13, 2010, at 6:47 AM, Lukas Renggli wrote:
The recent change of renaming #revese to #reversed introduces problems in the Seaside code-base.
While I agree that the renaming makes sense, #reverse is part of the ANSI standard and supported by all other Smalltalk implementations. In Seaside we are forced to use it.
Could Pharo re-add a not-deprecated delegator of #reverse in SequenceableCollection? I have the opinion that Pharo should follow ANSI if this is easily possible, because this is the only mean of having some minimal kind of compatibility.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
Marcus just did it. Now this is a pity since sorted returns a new collection and sort in Squeak (does a in place sort) In squeak too reverse "This method will be the in place version sometime" self deprecated: 'Use #reversed'. ^self reversed it was nice to have a coherent protocol. Stef On May 13, 2010, at 4:37 PM, Lukas Renggli wrote:
Please integrate this fix:
http://code.google.com/p/pharo/issues/detail?id=2428
On 13 May 2010 14:12, Lukas Renggli <renggli@gmail.com> wrote:
What ansi specifies for reversed?
The problem is that #reverse is deprecated in Pharo 1.1. I didn't look at the implementation of #reversed. If that can be fixed then Seaside 3.0 passes all tests in Pharo 1.1 (after I committed a few changes).
ANSI on reverse:
5.7.8.26 Message: reverse
Synopsis
Answer a collection with the elements of the receiver arranged in reverse order. Definition: <sequenceReadableCollection> Answer a collection conforming to the same protocols as the receiver, but with its elements arranged in reverse order. This operation is equivalent to: 1. Create a new collection which conforms to the same protocols as the receiver; 2. Traverse the elements of the receiver in the order specified by the #reverseDo: message, adding each element of the receiver to the new collection; 3. Answer the new collection.
Return Values <RECEIVER>
Errors none
On 13 May 2010 09:23, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes the idea was to have sort sorted reverse reversed
for inplace/copy based situation. What ansi specifies for reversed?
Stef
On May 13, 2010, at 6:47 AM, Lukas Renggli wrote:
The recent change of renaming #revese to #reversed introduces problems in the Seaside code-base.
While I agree that the renaming makes sense, #reverse is part of the ANSI standard and supported by all other Smalltalk implementations. In Seaside we are forced to use it.
Could Pharo re-add a not-deprecated delegator of #reverse in SequenceableCollection? I have the opinion that Pharo should follow ANSI if this is easily possible, because this is the only mean of having some minimal kind of compatibility.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Maybe it was easier to define reverse ^self reversed in a package of seaside with a category *Seaside-Pharo ? that's maybe what Dale did ? cheers mariano On Thu, May 13, 2010 at 6:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Marcus just did it.
Now this is a pity since sorted returns a new collection and sort in Squeak (does a in place sort)
In squeak too reverse "This method will be the in place version sometime"
self deprecated: 'Use #reversed'. ^self reversed
it was nice to have a coherent protocol.
Stef
On May 13, 2010, at 4:37 PM, Lukas Renggli wrote:
Please integrate this fix:
http://code.google.com/p/pharo/issues/detail?id=2428
On 13 May 2010 14:12, Lukas Renggli <renggli@gmail.com> wrote:
What ansi specifies for reversed?
The problem is that #reverse is deprecated in Pharo 1.1. I didn't look at the implementation of #reversed. If that can be fixed then Seaside 3.0 passes all tests in Pharo 1.1 (after I committed a few changes).
ANSI on reverse:
5.7.8.26 Message: reverse
Synopsis
Answer a collection with the elements of the receiver arranged in reverse order. Definition: <sequenceReadableCollection> Answer a collection conforming to the same protocols as the receiver, but with its elements arranged in reverse order. This operation is equivalent to: 1. Create a new collection which conforms to the same protocols as the receiver; 2. Traverse the elements of the receiver in the order specified by the #reverseDo: message, adding each element of the receiver to the new collection; 3. Answer the new collection.
Return Values <RECEIVER>
Errors none
On 13 May 2010 09:23, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes the idea was to have sort sorted reverse reversed
for inplace/copy based situation. What ansi specifies for reversed?
Stef
On May 13, 2010, at 6:47 AM, Lukas Renggli wrote:
The recent change of renaming #revese to #reversed introduces problems in the Seaside code-base.
While I agree that the renaming makes sense, #reverse is part of the ANSI standard and supported by all other Smalltalk implementations. In Seaside we are forced to use it.
Could Pharo re-add a not-deprecated delegator of #reverse in SequenceableCollection? I have the opinion that Pharo should follow ANSI if this is easily possible, because this is the only mean of having some minimal kind of compatibility.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Maybe it was easier to define
reverse     ^self reversed
in a package of seaside with a category *Seaside-Pharo ? that's maybe what Dale did ?
No, he changed the code to call #reversed. This however broke Seaside for all other platforms that properly implement the ANSI standard. Having a Seaside specific implementation would be feasible, but then we have to call it #greaseReverse or something, otherwise it will dirty the system package when loading. Even if the name is unfortunate, it doesn't make sense to break ANSI compatibility. This is the only thing we can trust on today for writing platform independent code. Lukas -- Lukas Renggli www.lukas-renggli.ch
participants (3)
-
Lukas Renggli -
Mariano Martinez Peck -
Stéphane Ducasse