first: / last:

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?

This sounds like a candidate for Sport.  Sport already helps with the way Gemstone streams are positioned, for example, so it should be possible to handle this in a similar way.

Sent from my phone.  Please forgive brevity.

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

[hidden email]

http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

Gemstone/S mailing list wrote

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)

Gemstone/S mailing list wrote

>Actually, I would argue against this. You want a #printAsLiteral or>something like that, implemented in all your dialects. In such a case, you
>take responsibility for ensuring the array can be represented literally.

True... and that's what do: we use our own string output methods.
But for printing an Array I think that #(1 2 3) is a more readable output than anArray( 1, 2, 3).

Gemstone/S mailing list wrote

But for printing an Array I think that #(1 2 3) is a more readable output than anArray( 1, 2, 3).

In VW an Array that is too big gets truncated with ' ...etc...) ', which tends to cause problems in generated scripts. So we use our own 'makeString' (as in a 'make' file) which is coded to work on GS and VW. 

Bob

On Monday, September 29, 2014 11:55 AM, Richard Sargent via GemStone-Smalltalk [hidden email] wrote:

Gemstone/S mailing list wrote
> But for printing an Array I think that #(1 2 3) is a more readable output
> than anArray( 1, 2, 3).

Hi Bob,

I just had this example printed in my VA transcript:
(#CompilationError #CompileError [] in
GbsSessionManager>>#initializeKernelConnectorConditions)

Putting a number sign in front is not going to make it readable. In fact,
even though I am not a fan of the GS way of printing an array, the commas
would improve readability of this example.



--
View this message in context: http://forum.world.st/first-last-tp4778749p4781288.html

Sent from the Gemstone/S mailing list archive at Nabble.com.
_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

-- 
Federico Mennite      Tel:       +41 91 611 17 35
Software Engineer     Fax:       +41 91 611 17 39
Lifeware SA           Web: http://www.lifeware.ch
Salita ai Ronchi 1, CH-6934 Bioggio (Switzerland) 

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 [hidden email] 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 [hidden email] 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) - [hidden email]

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

[hidden email]

http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

Gemstone/S mailing list wrote

Array>>storeString should avoid the truncation