Quantcast

first: / last:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

first: / last:

Gemstone/S mailing list
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. 

GS: #(a b c d e) copy last: 3; yourself  --> anArray( #'a', #'b', #'c', #'d', 3)
In the other dialects, we get: #(a b c d e) last: 3 -->   #(#c #d #e)

Any plans for this to change? 

Bob Nemec

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: first: / last:

Richard Sargent
Administrator
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: first: / last:

Gemstone/S mailing list

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.

On 18 Sep 2014 16:58, "Richard Sargent via GemStone-Smalltalk" <[hidden email]> wrote:
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: first: / last:

Gemstone/S mailing list
In reply to this post by Richard Sargent
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




--
Sent from the Gemstone/S mailing list archive at Nabble.com.
_______________________________________________
GemStone-Smalltalk mailing list


_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: first: / last:

Gemstone/S mailing list
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




--
Sent from the Gemstone/S mailing list archive at Nabble.com.
_______________________________________________
GemStone-Smalltalk mailing list


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: first: / last:

Gemstone/S mailing list
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




--
Sent from the Gemstone/S mailing list archive at Nabble.com.
_______________________________________________
GemStone-Smalltalk mailing list


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #printString [was Re: first: / last:]

Richard Sargent
Administrator
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)
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #printString [was Re: first: / last:]

Gemstone/S mailing list
>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).

Bob


On Friday, September 19, 2014 11:33 AM, Richard Sargent via GemStone-Smalltalk <[hidden email]> wrote:


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)

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.





--
View this message in context: http://forum.world.st/first-last-tp4778749p4779008.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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #printString [was Re: first: / last:]

Richard Sargent
Administrator
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).
For simple literal values, that is true. Once you start getting objects that don't print as literals, it gets less readable, especially with the separated "a" or "an" prefixes adding to the clutter.

And yet, we take pride in Smalltalk's near English syntax. So, using commas is closer to English than avoiding them. :-)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #printString [was Re: first: / last:]

Richard Sargent
Administrator
In reply to this post by Gemstone/S mailing list
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #printString [was Re: first: / last:]

Gemstone/S mailing list
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #printString [was Re: first: / last:]

Gemstone/S mailing list
Array>>storeString should avoid the truncation

On 30.09.2014 14:31, via GemStone-Smalltalk wrote:
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) 

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: first: / last:

Gemstone/S mailing list
In reply to this post by Gemstone/S mailing list
Hi,
in our environment we reimplemented Array>>printOn: and some of the #storeOn: methods in order to match VW's behavior.
Regards,
Federico


On 19.09.2014 15:01, via GemStone-Smalltalk 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)


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




--
Sent from the Gemstone/S mailing list archive at Nabble.com.
_______________________________________________
GemStone-Smalltalk mailing list


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #printString [was Re: first: / last:]

Richard Sargent
Administrator
In reply to this post by Gemstone/S mailing list
Gemstone/S mailing list wrote
Array>>storeString should avoid the truncation
That's true, but it's also not portable between GS and the client Smalltalks. GemStone's #storeString is not readily comprehensible to human readers and cannot be understood by VW or VA without quite a bit of work.

e.g.
(PassiveObject newWithContents: '^610^Array(4 ""Symbol(3 abc 123 Object(""
SymbolAssociation(
"key"?2 6 answer "value"42 ""

') activate



I am partial to the practice of implementing your own #storeOn: methods to emit the necessary, readable Smalltalk code to recreate the object instances. Of course, recursive references are problematic.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: first: / last:

Gemstone/S mailing list
In reply to this post by Gemstone/S mailing list
On Thu, Sep 18, 2014 at 3:20 PM, via GemStone-Smalltalk
<[hidden email]> 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.
>
> GS: #(a b c d e) copy last: 3; yourself  --> anArray( #'a', #'b', #'c',
> #'d', 3)
> In the other dialects, we get: #(a b c d e) last: 3 -->   #(#c #d #e)
>
> Any plans for this to change?

Not that it matters or anyone cares but coming from Squeak/Pharo I
have to admire the #first #first: symmetry in GemStone which matches
the "Smalltalk-getter-setter"-pattern.

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