[GemStone-Smalltalk] first: / last:

[via GemStone-Smalltalk]

I can understand the need to keep backward compatibility with base methods, but what about printString on Array?
Any chance it could be made to work like the VW & Pharo?

GS: #(a b c) printString -->  anArray( #'a', #'b', #'c')  ...    #(1 2 3) printString --> anArray( 1, 2, 3)
VW & Pharo: #(a b c) printString --> #(#a #b #c)  ...   #(1 2 3) printString -->  #(1 2 3)


With VW & Pharo you can evaluate the result and get an Array again.  Handy when building scripts.  

I use our own version of #displayString to get the string we need. 

I'd use storeString, but in my case I'm going across dialects (GS <> VW), and on GS it's a bit verbose...
#(1 2 3) storeString   --> (PassiveObject newWithContents: '^610^Array(3 ""1 2 3 ') activate

FWIW: VA is not good either... #(a b c)  --> (#a #b #c)  ...  #(1 2 3) -->  (1 2 3)


Bob


On Thursday, September 18, 2014 4:41 PM, via GemStone-Smalltalk <gemstone-smalltalk at lists.gemtalksystems.com> wrote:
 


We've implemented #copyFirst: and #copyLast: on GS and VW for ourselves ... I agree, those are better method names.

Bob Nemec


On Thursday, September 18, 2014 12:05 PM, Karsten Kusche via GemStone-Smalltalk <gemstone-smalltalk at lists.gemtalksystems.com> wrote:
 


Hi Richard, 

just some additional info about API: besides #first: and #last: there’s also #allButFirst: and #allButLast:, which make it extremely easy to access sub-collections without using copyFrom:to:. 

I do however agree that a „copy“ at the beginning of the selectors wouldn’t have hurt.

Kind Regards
Karsten

-- 

Karsten Kusche - Dipl. Inf. (FH) - karsten at heeg.de
Georg Heeg eK - Köthen
Handelsregister: Amtsgericht Dortmund A 12812 

Am Donnerstag, 18. September 2014 um 17:58 schrieb Richard Sargent via GemStone-Smalltalk:
Gemstone/S mailing list wrote
>The implementation of #first: and #last: in GemStone is very different
>>from VW, Pharo and VA. 
>>
>>
>>On GS the methods set the first or last value, in other dialects they
>>answer a copy with the first or last indexed values. 
>>
>>
>>...
>>
>>
>>Any plans for this to change? 
>
>
>In general, no. We try to avoid breaking applications that are working for
>our customers by avoiding changes in APIs.
>
>
>Personally, I would like to change things to make GemStone more compatible
>with other dialects, but as indicated, there are cases where we would create
>problems we don't want.
>
>
>I have issues with the concepts behind #first, #first:, #last, and #last:,
>especially when compared to other API methods. In some respects, the
>GemStone implementation is more consistent. I think #copyFrist: and
>#copyLast: would be better and more accurate names for the functions and
>would avoid the semantic imprecision associated with #first: and #last:.
>
>
>Richard
>
>
>
>
>
>
>
>
>--
>View this message in context: http://forum.world.st/first-last-tp4778749p4778800.html
>Sent from the Gemstone/S mailing list archive at Nabble.com.
>_______________________________________________
>GemStone-Smalltalk mailing list
>GemStone-Smalltalk at lists.gemtalksystems.com
>http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk


_______________________________________________
GemStone-Smalltalk mailing list
GemStone-Smalltalk at lists.gemtalksystems.com
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk




_______________________________________________
GemStone-Smalltalk mailing list
GemStone-Smalltalk at lists.gemtalksystems.com
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20140919/4f1efc49/attachment-0001.html>