I would like to integrate this elegant extension to the object-concatenation API. Just as Exceptions may be easily concatenated with the #, (comma) selector, now any object may, as well:
object1, object2 --> "{ object1. object2 }"
and, equally, with other collections:
{ object1. object2 }, object3 --> "{ object1. object2. object3 }"
I find this particularly useful for user-interfaces that apply Smalltalk interpretation to user text input, that the user was able to write "lists" of items in a very terse and natural way rather than demanding curly-brace developer-syntax.
I do not wish to reopen philosophical discussions; this is right in-line with the spirit of Squeak's other concatenation conveniences. There were no major objections when I proposed this a couple of months ago, and if that is still true, I would therefore like to go ahead and merge these 5 new methods into the trunk later this week.
- Chris
I missed that conversation. This is awesome, I love it; gimme the bits:)
+1
On Sun, Sep 19, 2010 at 1:53 PM, Chris Muller cmm@4dst.com wrote:
I would like to integrate this elegant extension to the object-concatenation API. Just as Exceptions may be easily concatenated with the #, (comma) selector, now any object may, as well:
object1, object2 --> "{ object1. object2 }"
and, equally, with other collections:
{ object1. object2 }, object3 --> "{ object1. object2. object3 }"
I find this particularly useful for user-interfaces that apply Smalltalk interpretation to user text input, that the user was able to write "lists" of items in a very terse and natural way rather than demanding curly-brace developer-syntax.
I do not wish to reopen philosophical discussions; this is right in-line with the spirit of Squeak's other concatenation conveniences. There were no major objections when I proposed this a couple of months ago, and if that is still true, I would therefore like to go ahead and merge these 5 new methods into the trunk later this week.
- Chris
On Sun, Sep 19, 2010 at 3:53 PM, Chris Muller cmm@4dst.com wrote:
I would like to integrate this elegant extension to the object-concatenation API. Just as Exceptions may be easily concatenated with the #, (comma) selector, now any object may, as well:
object1, object2 --> "{ object1. object2 }"
and, equally, with other collections:
{ object1. object2 }, object3 --> "{ object1. object2. object3 }"
Unless object3 is a collection? I assume that { 'this' 'is' }, 'wrong' will not give an array with three elements. Does #, test its argument to see if it is a collection, and either append or concatenate depending on what it is?
-Ralph
dear chris, i believe that this is not possible to do in a consistent manner, because: string , string means string concatenation object , object means collection creation
so it is not obvious (to me at least) what string , object object , string should actually do.
and then there's the fact that strings are collections too, so string , $c $c , string have yet another set of possible meanings.
just my 2c thanks wolfgang
On 19.09.2010 22:53, Chris Muller wrote:
I would like to integrate this elegant extension to the object-concatenation API. Just as Exceptions may be easily concatenated with the #, (comma) selector, now any object may, as well:
object1, object2 --> "{ object1. object2 }"
and, equally, with other collections:
{ object1. object2 }, object3 --> "{ object1. object2. object3 }"
I find this particularly useful for user-interfaces that apply Smalltalk interpretation to user text input, that the user was able to write "lists" of items in a very terse and natural way rather than demanding curly-brace developer-syntax.
I do not wish to reopen philosophical discussions; this is right in-line with the spirit of Squeak's other concatenation conveniences. There were no major objections when I proposed this a couple of months ago, and if that is still true, I would therefore like to go ahead and merge these 5 new methods into the trunk later this week.
- Chris
yeah, i think it is the case, when writing less terse:
{ obj1. obj2 }
instead of obj1 , obj2
is more preferable, since in case of using {} , obj1 and obj2 can be anything i like (including collections) and i don't have to expect any surprises from that.
On 20 September 2010 02:27, Wolfgang Eder edw@generalmagic.at wrote:
dear chris, i believe that this is not possible to do in a consistent manner, because: string , string means string concatenation object , object means collection creation
so it is not obvious (to me at least) what string , object object , string should actually do.
and then there's the fact that strings are collections too, so string , $c $c , string have yet another set of possible meanings.
just my 2c thanks wolfgang
On 19.09.2010 22:53, Chris Muller wrote:
I would like to integrate this elegant extension to the object-concatenation API. Just as Exceptions may be easily concatenated with the #, (comma) selector, now any object may, as well:
object1, object2 --> "{ object1. object2 }"
and, equally, with other collections:
{ object1. object2 }, object3 --> "{ object1. object2. object3 }"
I find this particularly useful for user-interfaces that apply Smalltalk interpretation to user text input, that the user was able to write "lists" of items in a very terse and natural way rather than demanding curly-brace developer-syntax.
I do not wish to reopen philosophical discussions; this is right in-line with the spirit of Squeak's other concatenation conveniences. There were no major objections when I proposed this a couple of months ago, and if that is still true, I would therefore like to go ahead and merge these 5 new methods into the trunk later this week.
- Chris
Hello,
i believe that this is not possible to do in a consistent manner, because: string , string means string concatenation object , object means collection creation
First, let me clarify that standard String concatenation is unaffected, of course. Nothing about this enhancement has any affect on any legacy code.
But to address your argument about consistency, String is already unique and pervasive, with other of its own idiosyncracies that are "inconsistent" with other kinds of objects. For example, consider String>>#= vs. Object>>#=. Even String>>#= vs. ByteArray>#=. Very, very different, and "not obvious" what String>#= should do without looking at the implementation.
so it is not obvious (to me at least) what string , object object , string should actually do.
It is based on the receiver of the message. Like the way you get different results from:
{ 1. 2. 3} difference: { 2. 3 }. { 2. 3} difference: { 1. 2. 3 }
depending on which is the receiver...
and then there's the fact that strings are collections too, so string , $c $c , string have yet another set of possible meanings.
This is the same meaning as above. The Character is the "object" and the receiver determines what happens..
Hope this helps, Chris
On 20.09.2010 19:24, Chris Muller wrote:
Hello,
i believe that this is not possible to do in a consistent manner, because: string , string means string concatenation object , object means collection creation
First, let me clarify that standard String concatenation is unaffected, of course. Nothing about this enhancement has any affect on any legacy code.
objection, your honor :) string concatenation fails if used with something else than strings. so your enhancements may cause to hide or change bugs.
But to address your argument about consistency, String is already unique and pervasive, with other of its own idiosyncracies that are "inconsistent" with other kinds of objects. For example, consider String>>#= vs. Object>>#=. Even String>>#= vs. ByteArray>#=. Very, very different, and "not obvious" what String>#= should do without looking at the implementation.
sounds obvious to me. = means test for equality.
so it is not obvious (to me at least) what string , object object , string should actually do.
It is based on the receiver of the message. Like the way you get different results from:
{ 1. 2. 3} difference: { 2. 3 }. { 2. 3} difference: { 1. 2. 3 }depending on which is the receiver...
yes, i understand what your enhancement does. it just that we disagree about whether it is beneficial to be able to use obj, obj instead of { obj. obj }
i happen to think the opposite (i.e. not beneficial) because it is not universal. i.e. it makes a difference string , object object , object
results in two different behaviours. thats what my concern is all about. thanks, wolfgang
and then there's the fact that strings are collections too, so string , $c $c , string have yet another set of possible meanings.
This is the same meaning as above. The Character is the "object" and the receiver determines what happens..
Hope this helps, Chris
it just that we disagree about whether it is beneficial to be able to use obj, obj instead of { obj. obj }
i happen to think the opposite (i.e. not beneficial) because it is not universal. i.e. it makes a difference string , object object , object
results in two different behaviours.
I agree, it looks akward and hackish to me too; a step backward from the nice API for collections we currently have.
Just my 2 cents of course...
Stef
I agree, it looks akward and hackish to me too; a step backward from the nice API for collections we currently have.
I guess I just don't understand why:
field1, field2, field3
looks "awkward and hackish?" It is the most natural way to express a "list" of things that you can possibly have...
You don't have use it. It's optional.
"Chris" == Chris Muller asqueaker@gmail.com writes:
I agree, it looks akward and hackish to me too; a step backward from the nice API for collections we currently have.
Chris> I guess I just don't understand why:
Chris> field1, field2, field3
Chris> looks "awkward and hackish?" It is the most natural way to express a Chris> "list" of things that you can possibly have...
Funny thing that. We already have:
{ field1 . field2 . field3 }
which to me reads even clearer.
Chris> You don't have use it. It's optional.
Until it hides a problem. Or breaks something else.
I vote no if I get a vote.
Randal, whoosh! I think you didn't read this thread closely. Please allow me to re-iterate, from my very original message of this thread:
I find this particularly useful for user-interfaces that apply Smalltalk interpretation to user text input, that the user was able to write "lists" of items in a very terse and natural way rather than demanding curly-brace developer-syntax.
And, again, in a subsequent message:
For non-technical users, the latter _is_ beneficial because it is more natural. I'm not talking about them writing Smalltalk methods, I'm talking about when they specify, for example, a list of columns in a text-input field in the user-interface that the program to which I apply Smalltalk interpretation (it's actually more sophisticated than that, but for sake of simple explanation..).
And, even again, a third time, the point showcased in a message all its own:
As a developer, I, too, always use the standard brace-notation for creating Arrays and will continue to do so. This has never been about introducing an enhanced-API to developers. My advocacy relates to exposing an API like this to a _non-developer_ user:
so you've definitely missed the overall point. As far as:
Until it hides a problem. Or breaks something else.
I will only say that I am not going to respond to any more FUD type of arguments.
- Chris
On Wed, Sep 22, 2010 at 1:08 PM, Randal L. Schwartz merlyn@stonehenge.com wrote:
"Chris" == Chris Muller asqueaker@gmail.com writes:
I agree, it looks akward and hackish to me too; a step backward from the nice API for collections we currently have.
Chris> I guess I just don't understand why:
Chris> field1, field2, field3
Chris> looks "awkward and hackish?" It is the most natural way to express a Chris> "list" of things that you can possibly have...
Funny thing that. We already have:
{ field1 . field2 . field3 }
which to me reads even clearer.
Chris> You don't have use it. It's optional.
Until it hides a problem. Or breaks something else.
I vote no if I get a vote.
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
2010/9/21 Wolfgang Eder edw@generalmagic.at:
string concatenation fails if used with something else than strings. so your enhancements may cause to hide or change bugs.
That's also my main concern, so -1ct from my corner.
Alex
First, let me clarify that standard String concatenation is unaffected, of course. Nothing about this enhancement has any affect on any legacy code.
objection, your honor :) string concatenation fails if used with something else than strings. so your enhancements may cause to hide or change bugs.
No, I don't think so.
'hello', Object new ---> "'helloan Object'"
Object new, 'hello' ---> "{an Object . $h . $e . $l . $l . $o}"
Where is the "failure?"
If you notice the timestamp on the methods, you will see that we have been using this for over five years. We have not noticed anything broken during that time. So, won't you please back up your claim with an example?
yes, i understand what your enhancement does. it just that we disagree about whether it is beneficial to be able to use obj, obj instead of { obj. obj }
It is not "instead of" it is "in addition to". It's use is optional. You are not forced to use it. However, I don't want to force my non-technical users to have to write
{ column1. column2. column 3. }
instead of
column1, column2, column3
For non-technical users, the latter _is_ beneficial because it is more natural. I'm not talking about them writing Smalltalk methods, I'm talking about when they specify, for example, a list of columns in a text-input field in the user-interface that the program to which I apply Smalltalk interpretation (it's actually more sophisticated than that, but for sake of simple explanation..).
i happen to think the opposite (i.e. not beneficial) because it is not universal. i.e. it makes a difference string , object object , object
I'm not sure what you mean by "not universal". That is like saying you are opposed to overloading in general..?? This is consistent with other overloads in that the receiver of the message determines the behavior, just like in other methods (like Collection>>#difference: which you did not address). If an Object receives it, you get a pointer-list of objects because the receiver is a pointer object. If a String receives it, you get a byte-list of characters because the receiver is a byte object. Isn't that completely consistent and logical.
----
So far the arguments presented against this are:
- "string concatenation fails if used with something else than strings" - "not beneficial" - "not universal" - "awkward and hackish"
I hope these are addressed these to your satisfaction. If not, at least you can opt out from using it and, in five years of using it, has presented no ill-effects on any legacy code..
- Chris
On 22.09.2010, at 18:14, Chris Muller wrote:
First, let me clarify that standard String concatenation is unaffected, of course. Nothing about this enhancement has any affect on any legacy code.
objection, your honor :) string concatenation fails if used with something else than strings. so your enhancements may cause to hide or change bugs.
No, I don't think so.
'hello', Object new ---> "'helloan Object'"
Object new, 'hello' ---> "{an Object . $h . $e . $l . $l . $o}"
Where is the "failure?"
If you notice the timestamp on the methods, you will see that we have been using this for over five years.
Stringification of any object in String>>, was only added last year. Until then, there was no generic protocol involving #, it was only for special classes (Collections, Exceptions, Sounds).
It made (some) sense for Strings because it's just too convenient being able to write ('the value is ', aNumber) without having to convert aNumber to a String first.
For making Arrays I prefer the brace notation. E.g. if you want to return two objects from a method you still would need to write ^{a. b} because if you write ^a,b would break if the first object happens to be a collection. Also, brace notation is more efficient with more than 2 elements because it avoids unnecessarily copying the intermediate collections.
That said, I wouldn't really mind adding your feature. It's just one more reason to advise people to avoid concatenation in production code whenever possible ;)
- Bert -
We have not noticed anything broken during that time. So, won't you please back up your claim with an example?
yes, i understand what your enhancement does. it just that we disagree about whether it is beneficial to be able to use obj, obj instead of { obj. obj }
It is not "instead of" it is "in addition to". It's use is optional. You are not forced to use it. However, I don't want to force my non-technical users to have to write
{ column1. column2. column 3. }
instead of
column1, column2, column3
For non-technical users, the latter _is_ beneficial because it is more natural. I'm not talking about them writing Smalltalk methods, I'm talking about when they specify, for example, a list of columns in a text-input field in the user-interface that the program to which I apply Smalltalk interpretation (it's actually more sophisticated than that, but for sake of simple explanation..).
i happen to think the opposite (i.e. not beneficial) because it is not universal. i.e. it makes a difference string , object object , object
I'm not sure what you mean by "not universal". That is like saying you are opposed to overloading in general..?? This is consistent with other overloads in that the receiver of the message determines the behavior, just like in other methods (like Collection>>#difference: which you did not address). If an Object receives it, you get a pointer-list of objects because the receiver is a pointer object. If a String receives it, you get a byte-list of characters because the receiver is a byte object. Isn't that completely consistent and logical.
So far the arguments presented against this are:
- "string concatenation fails if used with something else than strings"
- "not beneficial"
- "not universal"
- "awkward and hackish"
I hope these are addressed these to your satisfaction. If not, at least you can opt out from using it and, in five years of using it, has presented no ill-effects on any legacy code..
- Chris
As a developer, I, too, always use the standard brace-notation for creating Arrays and will continue to do so. This has never been about introducing an enhanced-API to developers. My advocacy relates to exposing an API like this to a _non-developer_ user:
myDatabase select: column1, column2, column3 where: [ : each | ... ]
so that this string, as entered by the user, without concern for brace-notation, can be simply evaluated by Smalltalk.
Thanks, Chris
On Wed, Sep 22, 2010 at 12:23 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 22.09.2010, at 18:14, Chris Muller wrote:
First, let me clarify that standard String concatenation is unaffected, of course. Nothing about this enhancement has any affect on any legacy code.
objection, your honor :) string concatenation fails if used with something else than strings. so your enhancements may cause to hide or change bugs.
No, I don't think so.
'hello', Object new ---> "'helloan Object'"
Object new, 'hello' ---> "{an Object . $h . $e . $l . $l . $o}"
Where is the "failure?"
If you notice the timestamp on the methods, you will see that we have been using this for over five years.
Stringification of any object in String>>, was only added last year. Until then, there was no generic protocol involving #, it was only for special classes (Collections, Exceptions, Sounds).
It made (some) sense for Strings because it's just too convenient being able to write ('the value is ', aNumber) without having to convert aNumber to a String first.
For making Arrays I prefer the brace notation. E.g. if you want to return two objects from a method you still would need to write ^{a. b} because if you write ^a,b would break if the first object happens to be a collection. Also, brace notation is more efficient with more than 2 elements because it avoids unnecessarily copying the intermediate collections.
That said, I wouldn't really mind adding your feature. It's just one more reason to advise people to avoid concatenation in production code whenever possible ;)
- Bert -
We have not noticed anything broken during that time. So, won't you please back up your claim with an example?
yes, i understand what your enhancement does. it just that we disagree about whether it is beneficial to be able to use obj, obj instead of { obj. obj }
It is not "instead of" it is "in addition to". It's use is optional. You are not forced to use it. However, I don't want to force my non-technical users to have to write
{ column1. column2. column 3. }
instead of
column1, column2, column3
For non-technical users, the latter _is_ beneficial because it is more natural. I'm not talking about them writing Smalltalk methods, I'm talking about when they specify, for example, a list of columns in a text-input field in the user-interface that the program to which I apply Smalltalk interpretation (it's actually more sophisticated than that, but for sake of simple explanation..).
i happen to think the opposite (i.e. not beneficial) because it is not universal. i.e. it makes a difference string , object object , object
I'm not sure what you mean by "not universal". That is like saying you are opposed to overloading in general..?? This is consistent with other overloads in that the receiver of the message determines the behavior, just like in other methods (like Collection>>#difference: which you did not address). If an Object receives it, you get a pointer-list of objects because the receiver is a pointer object. If a String receives it, you get a byte-list of characters because the receiver is a byte object. Isn't that completely consistent and logical.
So far the arguments presented against this are:
- "string concatenation fails if used with something else than strings" - "not beneficial" - "not universal" - "awkward and hackish"
I hope these are addressed these to your satisfaction. If not, at least you can opt out from using it and, in five years of using it, has presented no ill-effects on any legacy code..
- Chris
On Wed, Sep 22, 2010 at 10:49 AM, Chris Muller asqueaker@gmail.com wrote:
As a developer, I, too, always use the standard brace-notation for creating Arrays and will continue to do so. This has never been about introducing an enhanced-API to developers. My advocacy relates to exposing an API like this to a _non-developer_ user:
myDatabase select: column1, column2, column3 where: [ : each | ... ]
so that this string, as entered by the user, without concern for brace-notation, can be simply evaluated by Smalltalk.
Do you have a specific application in mind for this? Is there some reason it needs to be added to the base to be useful for your application?
On 9/22/2010 10:23 AM, Bert Freudenberg wrote:
Stringification of any object in String>>, was only added last year. Until then, there was no generic protocol involving #, it was only for special classes (Collections, Exceptions, Sounds).
It made (some) sense for Strings because it's just too convenient being able to write ('the value is ', aNumber) without having to convert aNumber to a String first.
For making Arrays I prefer the brace notation. E.g. if you want to return two objects from a method you still would need to write ^{a. b} because if you write ^a,b would break if the first object happens to be a collection. Also, brace notation is more efficient with more than 2 elements because it avoids unnecessarily copying the intermediate collections.
That said, I wouldn't really mind adding your feature.
Same here. I'm not a strong proponent of object-object concatenation (though I *am* a strong proponent of string-object concatenation :-) but I don't mind it either. I can sort of see the appeal of writing "1, 2" but it's just something that I don't do often outside of literal string concatenation.
From my view brace syntax is slightly advantageous for complex constructs since it avoids additional parenthesis and can be indented properly as in:
self doWithArgs: { self methodFoo: 42. 17 sqrt. 'Hello', 'World'. }
vs.
self doWithArgs: (self methodFoo: 42), 17 sqrt, ('Hello', 'World')
But then again I really don't feel strongly about it.
Cheers, - Andreas
On 22.09.2010, at 19:56, Andreas Raab wrote:
On 9/22/2010 10:23 AM, Bert Freudenberg wrote:
Stringification of any object in String>>, was only added last year. Until then, there was no generic protocol involving #, it was only for special classes (Collections, Exceptions, Sounds).
It made (some) sense for Strings because it's just too convenient being able to write ('the value is ', aNumber) without having to convert aNumber to a String first.
For making Arrays I prefer the brace notation. E.g. if you want to return two objects from a method you still would need to write ^{a. b} because if you write ^a,b would break if the first object happens to be a collection. Also, brace notation is more efficient with more than 2 elements because it avoids unnecessarily copying the intermediate collections.
That said, I wouldn't really mind adding your feature.
Same here. I'm not a strong proponent of object-object concatenation (though I *am* a strong proponent of string-object concatenation :-) but I don't mind it either. I can sort of see the appeal of writing "1, 2" but it's just something that I don't do often outside of literal string concatenation.
From my view brace syntax is slightly advantageous for complex constructs since it avoids additional parenthesis and can be indented properly as in:
self doWithArgs: { self methodFoo: 42. 17 sqrt. 'Hello', 'World'. }
vs.
self doWithArgs: (self methodFoo: 42), 17 sqrt, ('Hello', 'World')
Except that I know by looking at your first example that a 3-element-array will be passed. In the second case it depends on whether #methodFoo: returns a collection or not. If it does, this most probably does not what one would expect it to do.
- Bert -
2010/9/22 Andreas Raab andreas.raab@gmx.de:
On 9/22/2010 10:23 AM, Bert Freudenberg wrote:
Stringification of any object in String>>, was only added last year. Until then, there was no generic protocol involving #, it was only for special classes (Collections, Exceptions, Sounds).
It made (some) sense for Strings because it's just too convenient being able to write ('the value is ', aNumber) without having to convert aNumber to a String first.
For making Arrays I prefer the brace notation. E.g. if you want to return two objects from a method you still would need to write ^{a. b} because if you write ^a,b would break if the first object happens to be a collection. Also, brace notation is more efficient with more than 2 elements because it avoids unnecessarily copying the intermediate collections.
That said, I wouldn't really mind adding your feature.
Same here. I'm not a strong proponent of object-object concatenation (though I *am* a strong proponent of string-object concatenation :-) but I don't mind it either. I can sort of see the appeal of writing "1, 2" but it's just something that I don't do often outside of literal string concatenation.
Oh, in a more popular language, I just saw some code like aString += anInt; and started wondering what kind of tricky pointer arithmetic this would engage. In fact, it was just an implicit concatenation, dumb me ;) I thought I would have understood this pattern so much easily: aString += printString( anInt ); // excuse the smalltalkism here :) I vote 99/1 for the later in this context.
In Smalltalk context maybe it's different, I understand 'abc' , 33 very well.
The problem is about common sense expectations / least surprising results. For example, currently 'abc' , $d -> 'abcd' What would you decently expect from: $a , 'bcd' -> ? Chris, ask your end users if they really understand why concatenating a Character with a String should really answer an Array... OK, OK, we might implement Character>>#, with a proper rule...
But then, where to stop ? Following example was already used: #( 'one' 'two' ) , 'three'. 'three' , #( 'two' 'one' ). Probably none of the above will be of any use to, nor expected by any end user. So the end user argument does not hold to my sense, except if , is used in a restricted area, but then why implement it in Object ?
I also can understand the result of a message send is different according to the receiver. However using athe #difference: operator is a tricky argument : concatenation is more akin to sum / union isn't it?. Although not symetrical, I could decently expect it to be transitive. Like: self assert: (('abc' , $d ) , $e) = ('abc' , ($d , $e))
Plus some packages will insist on overriding #, to create a matrix, a Float array, or something...
Plus the efficiency problem already stated (multiple copies).
All in all, I find the (a,b,c) notation very bright, seducing and elegant, but also very deceiptive... It does not hold its promises.
Nicolas
From my view brace syntax is slightly advantageous for complex constructs since it avoids additional parenthesis and can be indented properly as in:
self doWithArgs: { self methodFoo: 42. 17 sqrt. 'Hello', 'World'. }
vs.
self doWithArgs: (self methodFoo: 42), 17 sqrt, ('Hello', 'World')
But then again I really don't feel strongly about it.
Cheers, - Andreas
In Smalltalk context maybe it's different, I understand 'abc' , 33 very well.
The problem is about common sense expectations / least surprising results. For example, currently 'abc' , $d -> 'abcd' What would you decently expect from: $a , 'bcd' -> ? Chris, ask your end users if they really understand why concatenating a Character with a String should really answer an Array...
$a , 'bcd' is no different than what they should decently expect from:
{ $a }, 'bcd'
Any guesses? It's the same answer. It's consistent, and not just in the answer but in the way it is equally "non-obvious". But I know you aren't going to protest concatenation of an Array of Characters with a String on those grounds.
These sorts of questions are irrelevant for the real-world scenario anyway. You all are critiquing on the wrong criteria. You are looking for some obscure way to mix a String, what we all know to be a special kind of Collection with special behaviors, with another kind of objects in order to "look for something non-obvious". C'mon now...
The fact is that heterogeneous collections are a rarity in real-world applications, but this is even a subset of those cases! e.g., this is some hypothetical heterogeneous collection of Strings, Objects, Characters that was "accidently" created by some junior programmer, because he used concatenation and it gave results he didn't expect (but should have), and he didn't test it and so planes fell out of the sky. Ohhh, the humanity of it!" :-)
I guess I'm feeling frustrated by having to fight so hard against all of these fake "problems" for a enhancement has absolutely _no bearing_ on any of your lives, but tangibly important for my application and users. It's just a simple way for them to express a list of objects in a natural way that can be directly interpreted. Nothing more.
I think you all should let me have this. If you don't use it, it can't affect you. We haven't run across a regression in the five years we've had this in our images, but if we do, I'll certainly fix it....
OK, OK, we might implement Character>>#, with a proper rule...
But then, where to stop ? Following example was already used: #( 'one' 'two' ) , 'three'. 'three' , #( 'two' 'one' ). Probably none of the above will be of any use to, nor expected by any end user. So the end user argument does not hold to my sense, except if , is used in a restricted area, but then why implement it in Object ?
I also can understand the result of a message send is different according to the receiver. However using athe #difference: operator is a tricky argument : concatenation is more akin to sum / union isn't it?. Although not symetrical, I could decently expect it to be transitive. Like: self assert: (('abc' , $d ) , $e) = ('abc' , ($d , $e))
Plus some packages will insist on overriding #, to create a matrix, a Float array, or something...
Plus the efficiency problem already stated (multiple copies).
All in all, I find the (a,b,c) notation very bright, seducing and elegant, but also very deceiptive... It does not hold its promises.
Nicolas
From my view brace syntax is slightly advantageous for complex constructs since it avoids additional parenthesis and can be indented properly as in:
self doWithArgs: { self methodFoo: 42. 17 sqrt. 'Hello', 'World'. }
vs.
self doWithArgs: (self methodFoo: 42), 17 sqrt, ('Hello', 'World')
But then again I really don't feel strongly about it.
Cheers, - Andreas
"Chris" == Chris Muller asqueaker@gmail.com writes:
Chris> I guess I'm feeling frustrated by having to fight so hard against all Chris> of these fake "problems" for a enhancement has absolutely _no bearing_ Chris> on any of your lives, but tangibly important for my application and Chris> users. It's just a simple way for them to express a list of objects Chris> in a natural way that can be directly interpreted. Nothing more.
OK, then add an override in your packages. I just don't want it in core.
It's too much dwimmery, in the same sense that I would object to nonBooleans all of a sudden being treated as true or false instead of rejecting them with MustBeBoolean, just because Ruby and Perl work that way. It doesn't feel like Smalltalk any more.
It would also have to be special cased for anything that wants to be portable with the other Smalltalks. Ugh.
Hi Chris,
just my opinion here.
Indeed the proposed code could be useful for developers. Some thing that I think is important is that when something is in the core image, it is an endorsement for use it. So, this change even isn't really a syntax change of smalltalk, in practice it is. Is some new syntax to write arrays. This gives the promise that can be used everywhere without adverse effects (like the ones others have highlighted), with uniformity in its usage and generally a good practice in smalltalk. Now this is not portable, because it will be only in Squeak, so if code begin to use it it will contain unportable code that will need to be changed, effectively reverting to a portable syntax and in fact putting aside your concatenation code. Also, you said that is for end users, and I think that you said non-developer users, but if that is the case, then why don't add this as part of the application are using, so that takes the input of the user and transform it to the underlying, portable, historical syntax, all transparent to the user. Now, if they are programming, then I think that they must now the real syntax and that they are using a facility provided by its application and not by the language.
Summary, I think that this belongs to a specific application code and not to the Squeak code base.
Just my opinion.
Cheers
El jue, 23-09-2010 a las 14:07 -0500, Chris Muller escribió:
In Smalltalk context maybe it's different, I understand 'abc' , 33 very well.
The problem is about common sense expectations / least surprising results. For example, currently 'abc' , $d -> 'abcd' What would you decently expect from: $a , 'bcd' -> ? Chris, ask your end users if they really understand why concatenating a Character with a String should really answer an Array...
$a , 'bcd' is no different than what they should decently expect from:
{ $a }, 'bcd'
Any guesses? It's the same answer. It's consistent, and not just in the answer but in the way it is equally "non-obvious". But I know you aren't going to protest concatenation of an Array of Characters with a String on those grounds.
These sorts of questions are irrelevant for the real-world scenario anyway. You all are critiquing on the wrong criteria. You are looking for some obscure way to mix a String, what we all know to be a special kind of Collection with special behaviors, with another kind of objects in order to "look for something non-obvious". C'mon now...
The fact is that heterogeneous collections are a rarity in real-world applications, but this is even a subset of those cases! e.g., this is some hypothetical heterogeneous collection of Strings, Objects, Characters that was "accidently" created by some junior programmer, because he used concatenation and it gave results he didn't expect (but should have), and he didn't test it and so planes fell out of the sky. Ohhh, the humanity of it!" :-)
I guess I'm feeling frustrated by having to fight so hard against all of these fake "problems" for a enhancement has absolutely _no bearing_ on any of your lives, but tangibly important for my application and users. It's just a simple way for them to express a list of objects in a natural way that can be directly interpreted. Nothing more.
I think you all should let me have this. If you don't use it, it can't affect you. We haven't run across a regression in the five years we've had this in our images, but if we do, I'll certainly fix it....
OK, OK, we might implement Character>>#, with a proper rule...
But then, where to stop ? Following example was already used: #( 'one' 'two' ) , 'three'. 'three' , #( 'two' 'one' ). Probably none of the above will be of any use to, nor expected by any end user. So the end user argument does not hold to my sense, except if , is used in a restricted area, but then why implement it in Object ?
I also can understand the result of a message send is different according to the receiver. However using athe #difference: operator is a tricky argument : concatenation is more akin to sum / union isn't it?. Although not symetrical, I could decently expect it to be transitive. Like: self assert: (('abc' , $d ) , $e) = ('abc' , ($d , $e))
Plus some packages will insist on overriding #, to create a matrix, a Float array, or something...
Plus the efficiency problem already stated (multiple copies).
All in all, I find the (a,b,c) notation very bright, seducing and elegant, but also very deceiptive... It does not hold its promises.
Nicolas
From my view brace syntax is slightly advantageous for complex constructs since it avoids additional parenthesis and can be indented properly as in:
self doWithArgs: { self methodFoo: 42. 17 sqrt. 'Hello', 'World'. }vs.
self doWithArgs: (self methodFoo: 42), 17 sqrt, ('Hello', 'World')But then again I really don't feel strongly about it.
Cheers,
- Andreas
Is some new syntax to write arrays. This gives the promise that can be used everywhere without adverse effects (like the ones others have highlighted), with uniformity in its usage and generally a good practice in smalltalk.
Exactly. This is a very good summary of why I wouldn't like the proposal to be included in the trunk.
Now about the term "concatenation": the proposal is not about concatenation at all, it is about collection making.
Concatenation of two objects leads to another object of more or less the same kind; it does not lead to a collection of the two initial objects. In Squeak #, is used for concatenation, braces for forming a collection out of objects.
These are two very different things; the proposal is reifying a confusion between them, effectively saying that in some unclear way anObject is anObject and {anObject} at the same time.
Would the proposal be accepted, such a confusion would potentially propagate everywhere; in my view, this is worse than actually breaking some code.
Stef
Let me illustrate my previous post with what I did in MuO.
MuO is a framework for music composition. Any MusicalElement represent some sort of musical data in a temporal framework.
Two MusicalElement instances can always be mixed; the resulting mix is always a MusicalElement.
Here enters the concatenation/collection making ambiguity.
If a is a MusicalNote, and b another MusicalNote, then
a,b
is a MusicalPhrase.
While if a and b are musicalPhrase, then
a,b
is also a MusicalPhrase.
This is in the line of Chris' proposal (which I am opposed to); the reason I find it meaningful here is that both MusicalNote and MusicalPhrase are subclasses of MusicalElement.
In the context of what a MusicalElement is, it makes sense that concatenation of two objects leads to an object of a different class, similar to a collection, because both the initial objects and the collection are assured to mix freely via the MusicalElement protocol.
In the general case though, there is no reason that the protocol (taken in the broadest sense, as "expected usage") applying to object also applies to a collection of objects. Indeed, a collection of object is generally ignorant of the nature of its elements. String is an exception and, guess what, String does generalize concatenation to non-String objects.
Similarly, AbstractSound implements #, in a way close to Chris' proposal, since if a and b are sounds then a,b is a SequentialSound (the analog of collection in that case). But note that SequentialSound in an AbstractSound.
So I think we have a pattern here: Chris' proposal make sense to me when it operates in a delimited domain where it is clear why we can consider anObject to also represent {anObject}. Such a domain implicitely states that its objects all have a structural property of potential multiplicity that makes it logical that the simplest of these objects can be considered as composed of themselves alone.
So a Character is a sort of singleton String, seen from the point of view of String. Similarly, an AbstractSound is a singleton SequentialSound, while a MusicalNote is a singleton MusicalPhrase, as seen by MusicalElement.
In this way of looking to the problem, Chris's proposal makes the point of view of Array important enough that any Object can be seen as an Array singleton.
That's where I disagree, for at least two reasons: - philosophically, I don't think Array is so central in Smalltalk that we have to look to every object through its eyes - practically, we have a rich set of Collections, so why pick up Array other IdentitySet or SequenceableCollection ?
sorry for the long post, hope it was clear...
Stef
Hey, brilliant explanation, thanks. I respect _this_ argument and, for the sake of moving on, will retract my proposal (sorry Brent!). But please consider my final thoughts that address your explanation, and I will now shut up.. :)
_Semantically_, I think it's reasonable to expect that, for most any kind of "Object", whether it's a musical-note or a coffee-mug, if you can have one of them, you can always consider the possibility of two or more. Yes, there are singletons, but a 98% case is worth a generalization in Object.
I do have three such cases across my various applications (in separate class-hierarchies), so it made sense for me to "factor" this concept into their common superclass, Object,
Object>>, aCollection ^ self asCollection, aCollection asCollection
rather than duplicated three times.
Now, notice how only the _abstract portion_ of our common "pattern" (as you rightly called it) is in Object. This implementation provides the general behavior needed for muO and all three of my apps (as well as String and SequentialSound, etc.) to express a list of their primary domain objects. Instead of muO implementing #, (comma) it would just implement #asCollection:
MusicalPhrase>>#asCollection ^ self
MusicalNote>>#asCollection ^ MusicalPhrase with: self
I probably should have tried to sell this angle to you earlier, but Object>>#, is not much code for me to duplicate. And, while we obviously agree that comma #, is a beautiful way to express a list, developers don't need it and the need for direct Smalltalk interpretation of _user_ input is probably rare.. OK!
(But I need to still consider Object>>#asCollection though, so I don't have to duplicate THAT in all three places too..)
Good debate, thanks Stef.
- Chris
2010/9/24 Stéphane Rollandin lecteur@zogotounga.net:
Let me illustrate my previous post with what I did in MuO.
MuO is a framework for music composition. Any MusicalElement represent some sort of musical data in a temporal framework.
Two MusicalElement instances can always be mixed; the resulting mix is always a MusicalElement.
Here enters the concatenation/collection making ambiguity.
If a is a MusicalNote, and b another MusicalNote, then
a,b
is a MusicalPhrase.
While if a and b are musicalPhrase, then
a,b
is also a MusicalPhrase.
This is in the line of Chris' proposal (which I am opposed to); the reason I find it meaningful here is that both MusicalNote and MusicalPhrase are subclasses of MusicalElement.
In the context of what a MusicalElement is, it makes sense that concatenation of two objects leads to an object of a different class, similar to a collection, because both the initial objects and the collection are assured to mix freely via the MusicalElement protocol.
In the general case though, there is no reason that the protocol (taken in the broadest sense, as "expected usage") applying to object also applies to a collection of objects. Indeed, a collection of object is generally ignorant of the nature of its elements. String is an exception and, guess what, String does generalize concatenation to non-String objects.
Similarly, AbstractSound implements #, in a way close to Chris' proposal, since if a and b are sounds then a,b is a SequentialSound (the analog of collection in that case). But note that SequentialSound in an AbstractSound.
So I think we have a pattern here: Chris' proposal make sense to me when it operates in a delimited domain where it is clear why we can consider anObject to also represent {anObject}. Such a domain implicitely states that its objects all have a structural property of potential multiplicity that makes it logical that the simplest of these objects can be considered as composed of themselves alone.
So a Character is a sort of singleton String, seen from the point of view of String. Similarly, an AbstractSound is a singleton SequentialSound, while a MusicalNote is a singleton MusicalPhrase, as seen by MusicalElement.
In this way of looking to the problem, Chris's proposal makes the point of view of Array important enough that any Object can be seen as an Array singleton.
That's where I disagree, for at least two reasons:
- philosophically, I don't think Array is so central in Smalltalk that we
have to look to every object through its eyes
- practically, we have a rich set of Collections, so why pick up Array other
IdentitySet or SequenceableCollection ?
sorry for the long post, hope it was clear...
Stef
"Stéphane" == Stéphane Rollandin lecteur@zogotounga.net writes:
Stéphane> Concatenation of two objects leads to another object of more Stéphane> or less the same kind; it does not lead to a collection of the Stéphane> two initial objects. In Squeak #, is used for concatenation, Stéphane> braces for forming a collection out of objects.
That says exactly what I had a gut level feel for. Thanks for verbalizing it.
squeak-dev@lists.squeakfoundation.org
-
Alexander Lazarević -
Andreas Raab -
Bert Freudenberg -
Casey Ransberger -
Chris Muller -
Chris Muller -
Colin Putney -
Igor Stasenko -
merlyn＠stonehenge.com -
Miguel Cobá -
Nicolas Cellier -
Ralph Johnson -
Stéphane Rollandin -
Wolfgang Eder