Ron,
================== It would appear that there is a fix for underscores but apparently the community at large does not support them. So although I agree that underscores in methods and class names *SHOULD* be supported, how does the team feel about removing them from our code? ==================
Do whatever you think is best. If you want to play along with the group to gain acceptance, so be it. If you want to draw an underscore in the sand, that's ok too (though we might lose the fight), I'll gladly add a voice to the background noise.
Squeak certainly should allow underscores in class names and selectors. Your example (TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) is extreme, but makes the point beyond ANSI and inter-dialect compatibility. The "it will break old code" argument is weak IMHO - old code outside the image has probably broken due to changes anyway, so the compiler errors are most likely just the beginning.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bills@anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
My biggest concern is that others will have trouble loading our code. I suppose that we could release the patch to allow underscores as part of our package, but then we will be responsible for watching that method for changes later. I still have not tried to find out why it works in my image. I wonder if it's an update from GLORP?
Rob, how did you finally get it to work, or did underscores in class names just work in windows?
Ron
From: Bill Schwab Sent: Friday, October 06, 2006 11:33 AM
Ron,
================== It would appear that there is a fix for underscores but apparently the community at large does not support them. So although I agree that underscores in methods and class names *SHOULD* be supported, how does the team feel about removing them from our code? ==================
Do whatever you think is best. If you want to play along with the group to gain acceptance, so be it. If you want to draw an underscore in the sand, that's ok too (though we might lose the fight), I'll gladly add a voice to the background noise.
Squeak certainly should allow underscores in class names and selectors. Your example (TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) is extreme, but makes the point beyond ANSI and inter-dialect compatibility. The "it will break old code" argument is weak IMHO - old code outside the image has probably broken due to changes anyway, so the compiler errors are most likely just the beginning.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bills@anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
On Oct 6, 2006, at 9:12 AM, Ron Teitelbaum wrote:
Rob, how did you finally get it to work, or did underscores in class names just work in windows?
A class name is just a symbol, so I just quoted it when defining the class.
Rob
Ron
From: Bill Schwab Sent: Friday, October 06, 2006 11:33 AM
Ron,
================== It would appear that there is a fix for underscores but apparently the community at large does not support them. So although I agree that underscores in methods and class names *SHOULD* be supported, how does the team feel about removing them from our code? ==================
Do whatever you think is best. If you want to play along with the group to gain acceptance, so be it. If you want to draw an underscore in the sand, that's ok too (though we might lose the fight), I'll gladly add a voice to the background noise.
Squeak certainly should allow underscores in class names and selectors. Your example (TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) is extreme, but makes the point beyond ANSI and inter-dialect compatibility. The "it will break old code" argument is weak IMHO - old code outside the image has probably broken due to changes anyway, so the compiler errors are most likely just the beginning.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bills@anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
What's your opinion about removing them from our code?
Ron
-----Original Message----- From: Robert Withers [mailto:reefedjib@yahoo.com] Sent: Friday, October 06, 2006 12:53 PM To: Ron@USMedRec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] Removing underscores
On Oct 6, 2006, at 9:12 AM, Ron Teitelbaum wrote:
Rob, how did you finally get it to work, or did underscores in class names just work in windows?
A class name is just a symbol, so I just quoted it when defining the class.
Rob
Ron
From: Bill Schwab Sent: Friday, October 06, 2006 11:33 AM
Ron,
================== It would appear that there is a fix for underscores but apparently the community at large does not support them. So although I agree that underscores in methods and class names *SHOULD* be supported, how does the team feel about removing them from our code? ==================
Do whatever you think is best. If you want to play along with the group to gain acceptance, so be it. If you want to draw an underscore in the sand, that's ok too (though we might lose the fight), I'll gladly add a voice to the background noise.
Squeak certainly should allow underscores in class names and selectors. Your example (TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) is extreme, but makes the point beyond ANSI and inter-dialect compatibility. The "it will break old code" argument is weak IMHO - old code outside the image has probably broken due to changes anyway, so the compiler errors are most likely just the beginning.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bills@anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Ron Teitelbaum schrieb:
What's your opinion about removing them from our code?
Ron
I'd say remove them underscores - at the moment they make more trouble than what they're worth. For names of classes and methods, we can use the CamelBack form. The main advantage of underscores is that they allow you to take names from existing APIs and use them as-is. This is especially valuable in generated code, but I don't think we need that here. Or do we?
Cheers, Hans-Martin
I agree. The names of the classes do come directly from the protocol, but their value is arguable. I agree with Bill though that interfaces to DB's is a good example of where underscores should be allowed. I really don't understand the argument for not allowing them, or the argument that they are aesthetically displeasing. They seem reasonable to me.
Given the potential problems for others to load the code absent a major argument within the community to allow them, I think we should remove them.
Ron
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Hans-Martin Mosner Sent: Friday, October 06, 2006 2:24 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] Removing underscores
Ron Teitelbaum schrieb:
What's your opinion about removing them from our code?
Ron
I'd say remove them underscores - at the moment they make more trouble than what they're worth. For names of classes and methods, we can use the CamelBack form. The main advantage of underscores is that they allow you to take names from existing APIs and use them as-is. This is especially valuable in generated code, but I don't think we need that here. Or do we?
Cheers, Hans-Martin _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Ron Teitelbaum schrieb:
I agree. The names of the classes do come directly from the protocol, but their value is arguable. I agree with Bill though that interfaces to DB's is a good example of where underscores should be allowed. I really don't understand the argument for not allowing them, or the argument that they are aesthetically displeasing. They seem reasonable to me.
Original Smalltalk-80 had a left-arrow glyph at character code 16r5F where ASCII has the underscore. In my opinion it was an unfortunate choice, but IIRC the development of ASCII and of Smalltalk somewhat overlapped in time, and at one point in time the ASCII precursor had left arrow and up arrow at the position where Smalltalk-80 used them for the assignment and return symbols. When I came to learn Smalltalk, I found the Smalltalk style of EmbeddedCaps much more visually pleasing than the style of ALL_UPPERCASE_LETTERS_WITH_UNDERSCORES which was prevalent in most programming languages at the time, but this was probably more due to the uppercase letters than the underscores. Nowadays, with Unicode as the character encoding of choice, there's not much reason left to disallow the underscore in identifiers, except the backwards compatibility argument. But I'm fairly sure that the Squeak community will burn that bridge one day - it might just not be tomorrow.
Cheers, Hans-Martin
Thanks for the explanation! It makes more sense now. I noticed that in my image aTemp_'hello' blew up but aTemp _ 'hello' didn't. It appeared to need a space to determine if the underscore was an assignment character. I would seem that the Unicode replacement of an arrow would be needed before allowing _ since it appears to support both.
Ron
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Hans-Martin Mosner Sent: Friday, October 06, 2006 2:56 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] Removing underscores
Ron Teitelbaum schrieb:
I agree. The names of the classes do come directly from the protocol,
but
their value is arguable. I agree with Bill though that interfaces to
DB's
is a good example of where underscores should be allowed. I really
don't
understand the argument for not allowing them, or the argument that they
are
aesthetically displeasing. They seem reasonable to me.
Original Smalltalk-80 had a left-arrow glyph at character code 16r5F where ASCII has the underscore. In my opinion it was an unfortunate choice, but IIRC the development of ASCII and of Smalltalk somewhat overlapped in time, and at one point in time the ASCII precursor had left arrow and up arrow at the position where Smalltalk-80 used them for the assignment and return symbols. When I came to learn Smalltalk, I found the Smalltalk style of EmbeddedCaps much more visually pleasing than the style of ALL_UPPERCASE_LETTERS_WITH_UNDERSCORES which was prevalent in most programming languages at the time, but this was probably more due to the uppercase letters than the underscores. Nowadays, with Unicode as the character encoding of choice, there's not much reason left to disallow the underscore in identifiers, except the backwards compatibility argument. But I'm fairly sure that the Squeak community will burn that bridge one day - it might just not be tomorrow.
Cheers, Hans-Martin _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Hi Ron--
Given the potential problems for others to load the code absent a major argument within the community to allow them, I think we should remove them.
I think that's the best argument, sadly.
I'll just throw out, though, that if we move to a system that can transfer behavior without requiring source code at all (e.g., Spoon[1]), then this issue is utterly moot.
-C
p.s.
I really don't understand.. the argument that they are aesthetically displeasing. They seem reasonable to me.
As I understand it, the underscore character is considered aesthetically displeasing because it's a typewriter hack, intended for underlining things (typing other characters, moving the carriage backward, and overtyping some underscores). It's considered ugly because it's an anachronism, and the subsequent hack of separating tokens in a human's mind within what a machine considers a single token is not sufficient to redeem it (and that the hack of using it for assignment is more worthwhile, mostly because it is displayed as something else).
For the sake of good taste and tact I will refrain from divulging my own personal opinion about it. ;)
cryptography@lists.squeakfoundation.org
-
Bill Schwab -
Craig Latta -
Hans-Martin Mosner -
Robert Withers -
Ron Teitelbaum