[Pharo-project] Pharo 1.1/1.2 and class names in Chinese
In 1.1 and 1.2, without setting a language environment for Chinese, I am able to use Chinese by setting fonts. It seems to work except for accepting a class named in Chinese will end in a ClassBuilder error of 'Class names must be capitalized'. Well is it a feature(requires language environment being set correctly) or bug? The code located being: validateClassName: aString "Validate the new class name" aString isSymbol ifFalse: [ ^ false ]. aString first canBeGlobalVarInitial ifFalse:[ self error: 'Class names must be capitalized'. ^false]. environ at: aString ifPresent:[:old| (old isKindOf: Behavior) ifFalse:[ self notify: aString asText allBold, ' already exists!\Proceed will store over it.' withCRs]]. ^ true and following the code the problemic method is #canBeGlobalVarInitial: which is found in two classes: in EncodedCharSet class side: canBeGlobalVarInitial: char | leadingChar | leadingChar := char leadingChar. leadingChar = 0 ifTrue: [^ self isUppercase: char]. ^ self isLetter: char. and in LanguageEnvironment canBeGlobalVarInitial: char ^ Unicode canBeGlobalVarInitial: char. I didn't set a Chinese environment and the exception is occured in in EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought to be lowercased. ----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p230... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I have no idea how to help you. But trying to have classes with chinese (or any other alphabet with accents) names is important. Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example. Cheers, Alexandre On 28 Jul 2010, at 21:33, empty wrote:
In 1.1 and 1.2, without setting a language environment for Chinese, I am able to use Chinese by setting fonts. It seems to work except for accepting a class named in Chinese will end in a ClassBuilder error of 'Class names must be capitalized'. Well is it a feature(requires language environment being set correctly) or bug?
The code located being:
validateClassName: aString "Validate the new class name"
aString isSymbol ifFalse: [ ^ false ]. aString first canBeGlobalVarInitial ifFalse:[ self error: 'Class names must be capitalized'. ^false]. environ at: aString ifPresent:[:old| (old isKindOf: Behavior) ifFalse:[ self notify: aString asText allBold, ' already exists!\Proceed will store over it.' withCRs]]. ^ true
and following the code the problemic method is #canBeGlobalVarInitial: which is found in two classes: in EncodedCharSet class side: canBeGlobalVarInitial: char
| leadingChar | leadingChar := char leadingChar.
leadingChar = 0 ifTrue: [^ self isUppercase: char]. ^ self isLetter: char.
and in LanguageEnvironment
canBeGlobalVarInitial: char
^ Unicode canBeGlobalVarInitial: char.
I didn't set a Chinese environment and the exception is occured in in EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought to be lowercased.
----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p230... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Folks, I think that is a mistake. Having Spanish as my mother tongue, I used to code with Spanish names before knowing Smalltalk. So when started using Smalltalk I kept doing it. Later I realized it is a bad idea. In Smalltalk there is no clear distinction between the "vendor libraries" and our own code. Our application specific classes will many times implement methods akin to existing ones in the system. Writing their names in English makes the whole system more consistent. Following this a little bit, it is better if all the code we write is in English too. OTOH, I believe it is ok to write comments in languages other than English (if the code will not be open sourced). I'd even suggest the system to reject names and selectors not in ASCII. Cheers, Juan Vuletich Alexandre Bergel wrote:
I have no idea how to help you. But trying to have classes with chinese (or any other alphabet with accents) names is important. Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example.
Cheers, Alexandre
On 28 Jul 2010, at 21:33, empty wrote:
In 1.1 and 1.2, without setting a language environment for Chinese, I am able to use Chinese by setting fonts. It seems to work except for accepting a class named in Chinese will end in a ClassBuilder error of 'Class names must be capitalized'. Well is it a feature(requires language environment being set correctly) or bug?
The code located being:
validateClassName: aString "Validate the new class name"
aString isSymbol ifFalse: [ ^ false ]. aString first canBeGlobalVarInitial ifFalse:[ self error: 'Class names must be capitalized'. ^false]. environ at: aString ifPresent:[:old| (old isKindOf: Behavior) ifFalse:[ self notify: aString asText allBold, ' already exists!\Proceed will store over it.' withCRs]]. ^ true
and following the code the problemic method is #canBeGlobalVarInitial: which is found in two classes: in EncodedCharSet class side: canBeGlobalVarInitial: char
| leadingChar | leadingChar := char leadingChar.
leadingChar = 0 ifTrue: [^ self isUppercase: char]. ^ self isLetter: char.
and in LanguageEnvironment
canBeGlobalVarInitial: char
^ Unicode canBeGlobalVarInitial: char.
I didn't set a Chinese environment and the exception is occured in in EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought to be lowercased.
----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p230... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3030 - Release Date: 07/26/10 15:34:00
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this... Cheers, Alexandre
Cheers, Juan Vuletich
Alexandre Bergel wrote:
I have no idea how to help you. But trying to have classes with chinese (or any other alphabet with accents) names is important. Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example.
Cheers, Alexandre
On 28 Jul 2010, at 21:33, empty wrote:
In 1.1 and 1.2, without setting a language environment for Chinese, I am able to use Chinese by setting fonts. It seems to work except for accepting a class named in Chinese will end in a ClassBuilder error of 'Class names must be capitalized'. Well is it a feature(requires language environment being set correctly) or bug?
The code located being:
validateClassName: aString "Validate the new class name"
aString isSymbol ifFalse: [ ^ false ]. aString first canBeGlobalVarInitial ifFalse:[ self error: 'Class names must be capitalized'. ^false]. environ at: aString ifPresent:[:old| (old isKindOf: Behavior) ifFalse:[ self notify: aString asText allBold, ' already exists!\Proceed will store over it.' withCRs]]. ^ true
and following the code the problemic method is #canBeGlobalVarInitial: which is found in two classes: in EncodedCharSet class side: canBeGlobalVarInitial: char
| leadingChar | leadingChar := char leadingChar.
leadingChar = 0 ifTrue: [^ self isUppercase: char]. ^ self isLetter: char.
and in LanguageEnvironment
canBeGlobalVarInitial: char
^ Unicode canBeGlobalVarInitial: char.
I didn't set a Chinese environment and the exception is occured in in EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought to be lowercased.
----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p230... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3030 - Release Date: 07/26/10 15:34:00
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
If I'm writing code for a project I mean to share, I write the code in english of course. But at my work, where I have to deal with very specific vocabulary that could be almost ridiculous to translate, I feel more comfortable writing in spanish (my native language) and not forcing the domain to be translated. I don't think it's a beginner's thing, I think it's just confortable for anyone depending on the objective of the project and working context. But yes, I find myself writing ugly selectors like "add*Indice*:" instead of "addIndex:" or "*agregarIndice*:" and stuff like that, but I choose to see "add..." more as a convention instead of another language :P Even if I were writing in english, I'd follow that convention. "*Indice*" means a domain specific concept in my work, and might even be confused with some collection index, for example. Besides all this, it's something that happens not only in Smalltalk but any language I can think about, specially if you use shared libraries or frameworks. The thing here is that Smalltalk classes must begin with capital letters. But what if your language doesn't have capital letters, even more funny, what if it doesn't have any *letters*? XD And thinking about that, here's a newbie and maybe stupid question: why do classes have to begin with a capital letter? Is it a technical issue or just following conventions? If the answer is following conventions*... well... just as I follow the "add" convention, unfortunately I'd suggest following the "classes with capital letters in ASCII" too :( :( *or maybe classes are identified as such by the compiler when they begin with capital letters *because* of the existing convention... Carla On Wed, Jul 28, 2010 at 5:48 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Cheers, Alexandre
Cheers, Juan Vuletich
Alexandre Bergel wrote:
I have no idea how to help you. But trying to have classes with chinese
(or any other alphabet with accents) names is important.
Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example.
Cheers, Alexandre
On 28 Jul 2010, at 21:33, empty wrote:
In 1.1 and 1.2, without setting a language environment for Chinese, I am able to use Chinese by setting fonts. It seems to work except for accepting a class named in Chinese will end in a ClassBuilder error of 'Class names must be capitalized'. Well is it a feature(requires language environment being set correctly) or bug?
The code located being:
validateClassName: aString "Validate the new class name"
aString isSymbol ifFalse: [ ^ false ]. aString first canBeGlobalVarInitial ifFalse:[ self error: 'Class names must be capitalized'. ^false]. environ at: aString ifPresent:[:old| (old isKindOf: Behavior) ifFalse:[ self notify: aString asText allBold, ' already exists!\Proceed will store over it.' withCRs]]. ^ true
and following the code the problemic method is #canBeGlobalVarInitial: which is found in two classes: in EncodedCharSet class side: canBeGlobalVarInitial: char
| leadingChar | leadingChar := char leadingChar.
leadingChar = 0 ifTrue: [^ self isUppercase: char]. ^ self isLetter: char.
and in LanguageEnvironment
canBeGlobalVarInitial: char
^ Unicode canBeGlobalVarInitial: char.
I didn't set a Chinese environment and the exception is occured in in EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought to be lowercased.
----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p230... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database:
271.1.1/3030 - Release Date: 07/26/10 15:34:00
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Once upon a time I wondered if it wouldn't be possible to translate the whole sources in any language (via a Dictionary). In any other language, we (think of a child) must learn to "talk' to computer in computer own language... So an apprentice has to learn a new language anyway Be it an english computer language is thus not that important. However, one of the nice properties of Smalltalk is enabling "talking" to the machine in a language close to our natural language, and that lowers the barriers. So the question of natural language naturally arises. The translation could be performed statically (transforming a whole image)... Or tools could as well perform the translation dynamically (using AST)... In the former case, we must maintain dictionaries if we want to continue sharing code with rest of the world. In the later case, if user adds a method #foo that already has a translation #bar, the effect might be surprising... (where the hell is my method foo ?). The problem is rather unlikely in English-Chinese conversions though ;) Untill there is such universal translations available, I agree with Juan: in long term, it's better/easier to use a single language wrt uniformity/homogeneity. I personnally started with franglishe, but tend to use English more and more... ...well, what I perceive as good English might hurt some ears ;). Nicolas 2010/7/28 Alexandre Bergel <alexandre@bergel.eu>:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Cheers, Alexandre
Cheers, Juan Vuletich
Alexandre Bergel wrote:
I have no idea how to help you. But trying to have classes with chinese (or any other alphabet with accents) names is important. Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example.
Cheers, Alexandre
On 28 Jul 2010, at 21:33, empty wrote:
In 1.1 and 1.2, without setting a language environment for Chinese, I am able to use Chinese by setting fonts. It seems to work except for accepting a class named in Chinese will end in a ClassBuilder error of 'Class names must be capitalized'. Well is it a feature(requires language environment being set correctly) or bug?
The code located being:
validateClassName: aString   "Validate the new class name"
  aString isSymbol       ifFalse: [ ^ false ].   aString first canBeGlobalVarInitial ifFalse:[       self error: 'Class names must be capitalized'.       ^false].   environ at: aString ifPresent:[:old|       (old isKindOf: Behavior) ifFalse:[           self notify: aString asText allBold,                       ' already exists!\Proceed will store over it.' withCRs]].   ^ true
and following the code the problemic method is #canBeGlobalVarInitial: which is found in two classes: in EncodedCharSet class side: canBeGlobalVarInitial: char
  | leadingChar |   leadingChar := char leadingChar.
  leadingChar = 0 ifTrue: [^ self isUppercase: char].   ^ self isLetter: char.
and in LanguageEnvironment
canBeGlobalVarInitial: char
  ^ Unicode canBeGlobalVarInitial: char.
I didn't set a Chinese environment and the exception is occured in in EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought to be lowercased.
----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p230... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 ------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3030 - Release Date: 07/26/10 15:34:00
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/7/28 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Once upon a time I wondered if it wouldn't be possible to translate the whole sources in any language (via a Dictionary). In any other language, we  (think of a child) must learn to "talk' to computer in computer own language... So an apprentice has to learn a new language anyway Be it an english computer language is thus not that important. However, one of the nice properties of Smalltalk is enabling "talking" to the machine in a language close to our natural language, and that lowers the barriers. So the question of natural language naturally arises.
The translation could be performed statically (transforming a whole image)... Or tools could as well perform the translation dynamically (using AST)...
In the former case, we must maintain dictionaries if we want to continue sharing code with rest of the world. In the later case, if user adds a method #foo that already has a translation #bar, the effect might be surprising... (where the hell is my method foo ?). The problem is rather unlikely in English-Chinese conversions though ;)
Untill there is such universal translations available, I agree with Juan:
One thing I forgot to notice : who never been upset by Excel translations of functions ?
in long term, it's better/easier to use a single language wrt uniformity/homogeneity. I personnally started with franglishe, but tend to use English more and more... ...well, what I perceive as good English might hurt some ears ;).
Nicolas
2010/7/28 Alexandre Bergel <alexandre@bergel.eu>:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Cheers, Alexandre
Cheers, Juan Vuletich
Alexandre Bergel wrote:
I have no idea how to help you. But trying to have classes with chinese (or any other alphabet with accents) names is important. Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example.
Cheers, Alexandre
On 28 Jul 2010, at 21:33, empty wrote:
In 1.1 and 1.2, without setting a language environment for Chinese, I am able to use Chinese by setting fonts. It seems to work except for accepting a class named in Chinese will end in a ClassBuilder error of 'Class names must be capitalized'. Well is it a feature(requires language environment being set correctly) or bug?
The code located being:
validateClassName: aString   "Validate the new class name"
  aString isSymbol       ifFalse: [ ^ false ].   aString first canBeGlobalVarInitial ifFalse:[       self error: 'Class names must be capitalized'.       ^false].   environ at: aString ifPresent:[:old|       (old isKindOf: Behavior) ifFalse:[           self notify: aString asText allBold,                       ' already exists!\Proceed will store over it.' withCRs]].   ^ true
and following the code the problemic method is #canBeGlobalVarInitial: which is found in two classes: in EncodedCharSet class side: canBeGlobalVarInitial: char
  | leadingChar |   leadingChar := char leadingChar.
  leadingChar = 0 ifTrue: [^ self isUppercase: char].   ^ self isLetter: char.
and in LanguageEnvironment
canBeGlobalVarInitial: char
  ^ Unicode canBeGlobalVarInitial: char.
I didn't set a Chinese environment and the exception is occured in in EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought to be lowercased.
----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p230... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 ------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3030 - Release Date: 07/26/10 15:34:00
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Well, that last comment reminded me of something: I've read code written in english by people that clearly didn't know a lot of english, and it kept me weeks thinking that the code did something that it didn't (and, of course, it was more difficult to realize why the code didn't behave like it was saying :P). So... as writing everything in english can be a solution, it can be a big problem too :( On Wed, Jul 28, 2010 at 6:32 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Once upon a time I wondered if it wouldn't be possible to translate the whole sources in any language (via a Dictionary). In any other language, we (think of a child) must learn to "talk' to computer in computer own language... So an apprentice has to learn a new language anyway Be it an english computer language is thus not that important. However, one of the nice properties of Smalltalk is enabling "talking" to the machine in a language close to our natural language, and that lowers the barriers. So the question of natural language naturally arises.
The translation could be performed statically (transforming a whole image)... Or tools could as well perform the translation dynamically (using AST)...
In the former case, we must maintain dictionaries if we want to continue sharing code with rest of the world. In the later case, if user adds a method #foo that already has a translation #bar, the effect might be surprising... (where the hell is my method foo ?). The problem is rather unlikely in English-Chinese conversions though ;)
Untill there is such universal translations available, I agree with Juan: in long term, it's better/easier to use a single language wrt uniformity/homogeneity. I personnally started with franglishe, but tend to use English more and more... ...well, what I perceive as good English might hurt some ears ;).
Nicolas
2010/7/28 Alexandre Bergel <alexandre@bergel.eu>:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Cheers, Alexandre
Cheers, Juan Vuletich
Alexandre Bergel wrote:
I have no idea how to help you. But trying to have classes with chinese
(or any other alphabet with accents) names is important.
Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example.
Cheers, Alexandre
On 28 Jul 2010, at 21:33, empty wrote:
In 1.1 and 1.2, without setting a language environment for Chinese, I am able to use Chinese by setting fonts. It seems to work except for accepting a class named in Chinese will end in a ClassBuilder error of 'Class names must be capitalized'. Well is it a feature(requires language environment being set correctly) or bug?
The code located being:
validateClassName: aString "Validate the new class name"
aString isSymbol ifFalse: [ ^ false ]. aString first canBeGlobalVarInitial ifFalse:[ self error: 'Class names must be capitalized'. ^false]. environ at: aString ifPresent:[:old| (old isKindOf: Behavior) ifFalse:[ self notify: aString asText allBold, ' already exists!\Proceed will store over it.' withCRs]]. ^ true
and following the code the problemic method is #canBeGlobalVarInitial: which is found in two classes: in EncodedCharSet class side: canBeGlobalVarInitial: char
| leadingChar | leadingChar := char leadingChar.
leadingChar = 0 ifTrue: [^ self isUppercase: char]. ^ self isLetter: char.
and in LanguageEnvironment
canBeGlobalVarInitial: char
^ Unicode canBeGlobalVarInitial: char.
I didn't set a Chinese environment and the exception is occured in in EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought to be lowercased.
----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p230... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database:
271.1.1/3030 - Release Date: 07/26/10 15:34:00
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/7/28 Carla F. Griggio <carla.griggio@gmail.com>
Well, that last comment reminded me of something:
I've read code written in english by people that clearly didn't know a lot of english, and it kept me weeks thinking that the code did something that it didn't (and, of course, it was more difficult to realize why the code didn't behave like it was saying :P). So... as writing everything in english can be a solution, it can be a big problem too :(
And a lot (majority ?) of developpers don't want to use English, or don't understand English, or don't want to try to understand English, or don't have the courage to try to understand English. And they need to communicate their ideas / code with others developpers in the same position :) I don't like writing in French, it's not suitable for programming. Have you ever seen WinDev code with auto-translation ? You end with: i est un entier. x, y sont des entiers. But I think it should be possible to have code in Chinese. Laurent
On Wed, Jul 28, 2010 at 6:32 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Once upon a time I wondered if it wouldn't be possible to translate the whole sources in any language (via a Dictionary). In any other language, we (think of a child) must learn to "talk' to computer in computer own language... So an apprentice has to learn a new language anyway Be it an english computer language is thus not that important. However, one of the nice properties of Smalltalk is enabling "talking" to the machine in a language close to our natural language, and that lowers the barriers. So the question of natural language naturally arises.
The translation could be performed statically (transforming a whole image)... Or tools could as well perform the translation dynamically (using AST)...
In the former case, we must maintain dictionaries if we want to continue sharing code with rest of the world. In the later case, if user adds a method #foo that already has a translation #bar, the effect might be surprising... (where the hell is my method foo ?). The problem is rather unlikely in English-Chinese conversions though ;)
Untill there is such universal translations available, I agree with Juan: in long term, it's better/easier to use a single language wrt uniformity/homogeneity. I personnally started with franglishe, but tend to use English more and more... ...well, what I perceive as good English might hurt some ears ;).
Nicolas
2010/7/28 Alexandre Bergel <alexandre@bergel.eu>:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Cheers, Alexandre
Cheers, Juan Vuletich
Alexandre Bergel wrote:
I have no idea how to help you. But trying to have classes with
chinese (or any other alphabet with accents) names is important.
Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example.
Cheers, Alexandre
On 28 Jul 2010, at 21:33, empty wrote:
In 1.1 and 1.2, without setting a language environment for Chinese, I am able to use Chinese by setting fonts. It seems to work except for accepting a class named in Chinese will end in a ClassBuilder error of 'Class names must be capitalized'. Well is it a feature(requires language environment being set correctly) or bug?
The code located being:
validateClassName: aString "Validate the new class name"
aString isSymbol ifFalse: [ ^ false ]. aString first canBeGlobalVarInitial ifFalse:[ self error: 'Class names must be capitalized'. ^false]. environ at: aString ifPresent:[:old| (old isKindOf: Behavior) ifFalse:[ self notify: aString asText allBold, ' already exists!\Proceed will store over it.' withCRs]]. ^ true
and following the code the problemic method is #canBeGlobalVarInitial: which is found in two classes: in EncodedCharSet class side: canBeGlobalVarInitial: char
| leadingChar | leadingChar := char leadingChar.
leadingChar = 0 ifTrue: [^ self isUppercase: char]. ^ self isLetter: char.
and in LanguageEnvironment
canBeGlobalVarInitial: char
^ Unicode canBeGlobalVarInitial: char.
I didn't set a Chinese environment and the exception is occured in in EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought to be lowercased.
----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p230... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database:
271.1.1/3030 - Release Date: 07/26/10 15:34:00
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 29/07/2010 03:10, laurent laffont < laurent.laffont@gmail.com > escreveu:
On Wed, Jul 28, 2010 at 6:32 PM, Nicolas Cellier wrote:
Once upon a time I wondered if it wouldn't be possible to translate the whole sources in any language (via a Dictionary). In any other language, we (think of a child) must learn to "talk' to computer in computer own language... So an apprentice has to learn a new language anyway Be it an english computer language is thus not that important. However, one of the nice properties of Smalltalk is enabling "talking" to the machine in a language close to our natural language, and that lowers the barriers. So the question of natural language naturally arises.
2010/7/28 Carla F. Griggio Well, that last comment reminded me of something: I've read code written in english by people that clearly didn't know a lot of english, and it kept me weeks thinking that the code did something that it didn't (and, of course, it was more difficult to realize why the code didn't behave like it was saying :P). So... as writing everything in english can be a solution, it can be a big problem too :(
And a lot (majority ?) of developpers don't want to use English, or don't understand English, or don't want to try to understand English, or don't have the courage to try to understand English. And they need to communicate their ideas / code with others developpers in the same position :)
I think you're heading to a position I've already discussed several years ago with Jecel (not surprisingly when he was teaching a tutorial on Smalltalk) on the issue of non native English speakers 'lose' a bit of the user friendliness of certain programming languages because they need to create a full 'dictionary' in their heads about a certain programming concept and the [foreign] language they need to memorize. He gave this example (IIRC): NNN FOR I=1 TO 120 NEXT I which for the Canadian boys he was accompanying they read as 'natural language', whereas Brazilian children had to memorize that the 'tokens' "FOR" "TO" and "NEXT" had to written in a certain syntax to create a loop in this language. The same happens in Smalltalk as most of the methods being in English, when I. Tomek in his book or introductory paper mentions that it is natural to have in Smalltalk: |rusty| rusty := Dog new. rusty bark. For a non native English speaker this syntax is tantamount to some obscure mathematical notation.
I don't like writing in French, it's not suitable for programming. Have you ever seen WinDev code with auto-translation ?
I cannot tell if it was successful or not but I remember in the seventies it was reported that in France there was an attempt to translate to French the COBOL keywords. Any account on the outcome of that?
You end with: i est un entier. x, y sont des entiers. But I think it should be possible to have code in Chinese.
I think it should be possible to have code coded in such a way it could be written in Chinese and understood [tranlated?] in any language in use in the planet ;-) Cheers, -- Cesar Rabak
On Fri, Jul 30, 2010 at 1:29 AM, <csrabak@bol.com.br> wrote:
Em 29/07/2010 03:10, laurent laffont < laurent.laffont@gmail.com > escreveu:
On  Wed,  Jul  28,  2010  at  6:32  PM,  Nicolas  Cellier  wrote:
Once  upon a  time  I wondered  if  it wouldn't  be possible  to  translate the whole sources in any language (via a Dictionary).  In  any other language,  we (think  of a  child) must  learn to  "talk'  to  computer  in  computer  own  language...  So  an  apprentice has to learn a  new language anyway Be it an english  computer language is thus  not that important.  However, one of  the nice  properties of Smalltalk is enabling  "talking" to the  machine in a  language close to our natural  language, and that  lowers  the  barriers.  So  the  question  of natural  language  naturally arises.
2010/7/28 Carla F.  Griggio  Well, that  last comment reminded me of  something: I've read code written in  english by people that clearly didn't know a lot of english, and it kept me weeks thinking that the code did  something  that  it  didn't  (and, of  course,  it  was  more difficult to  realize why the  code didn't  behave like  it was  saying :P).  So... as writing everything in  english can be a solution, it can  be a big problem too :(
 And a lot (majority ?) of developpers don't want to use English, or don't  understand  English,  or  don't  want to  try  to  understand English, or don't have the courage to try to understand English. And they need to communicate their  ideas / code with others developpers in the same position :)
I think you're heading to a position I've already discussed several years ago with Jecel (not surprisingly when he was teaching a tutorial on Smalltalk) on the issue of non native English speakers 'lose' a bit of the user friendliness of certain programming languages because they need to create a full 'dictionary' in their heads about a certain programming concept and the [foreign] language they need to memorize. Â He gave this example (IIRC):
NNN FOR I=1 TO 120 NEXT I
which for the Canadian boys he was accompanying they read as 'natural language', whereas Brazilian children had to memorize that the 'tokens' "FOR" "TO" and "NEXT" had to written in a certain syntax to create a loop in this language.
The same happens in Smalltalk as most of the methods being in English, when I. Tomek in his book or introductory paper mentions that it is natural to have in Smalltalk:
|rusty|
rusty := Dog new.
rusty bark.
For a non native English speaker this syntax is tantamount to some obscure mathematical notation.
 I  don't  like  writing  in  French,  it's  not  suitable  for programming. Have you ever  seen WinDev code with auto-translation ?
I cannot tell if it was successful or not but I remember in the seventies it was reported that in France there was an attempt to translate to French the COBOL keywords. Â Any account on the outcome of that?
I dunno of the translation of COBOL in french, but i remember when i was in high school in the 80ies having using applications built in LSE (Language Symbolique d'Enseignement). It was a kind of BASIC written in french. More information here: http://en.wikipedia.org/wiki/LSE_%28programming_language%29 and in french here: http://fr.wikipedia.org/wiki/LSE_%28langage_de_programmation%29 I remember doing german lessons with LSE programs. One way to trick the programs was to stop the application, to look at the name of variable used to give the answer. After that everytime you replyed with the name of variable, every exercice was done right ! Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Em 30/07/2010 01:12, Serge Stinckwich < serge.stinckwich@gmail.com > escreveu:
I dunno of the translation of COBOL in french, but i remember when i was in high school in the 80ies having using applications built in LSE (Language Symbolique d'Enseignement). It was a kind of BASIC written in french. More information here: http://en.wikipedia.org/wiki/LSE_%28programming_language%29 and in french here: http://fr.wikipedia.org/wiki/LSE_%28langage_de_programmation%29 I remember doing german lessons with LSE programs. One way to trick the programs was to stop the application, to look at the name of variable used to give the answer. After that everytime you replyed with the name of variable, every exercice was done right !
;-) Here in Brasil in the seventies we had a didactic programming language called HIPO (which is the suffix for Hypothetical in Portuguese) which was sort of the MIX language devised by D. Knuth. In the eighties a Pascal like language called LEAL (which means 'loyal' in Portuguese) was issued. But no tricks like the discovered by you have been reported for these educational languages... []s -- Cesar Rabak
On 07/28/2010 10:48 PM, Alexandre Bergel wrote:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Are you sure all your subsystems (changesets, fileouts, changes file, Monticello, ...) are Unicode aware? Do you use Unicode normalization? If so which one? Cheers Philippe
On 07/29/2010 09:23 AM, Philippe Marschall wrote:
On 07/28/2010 10:48 PM, Alexandre Bergel wrote:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Are you sure all your subsystems (changesets, fileouts, changes file, Monticello, ...) are Unicode aware? Do you use Unicode normalization? If so which one?
Do you know what the problem is when someone posts a "Invalid utf8 input detected" on this list and how to fix it? Cheers Philippe
On Jul 29, 2010, at 9:23 54AM, Philippe Marschall wrote:
On 07/28/2010 10:48 PM, Alexandre Bergel wrote:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Are you sure all your subsystems (changesets, fileouts, changes file, Monticello, ...) are Unicode aware? Do you use Unicode normalization? If so which one?
Cheers Philippe
+1. Venture outside the ascii-range, and you are asking for trouble when storing code externally. AFAIK, only the .sources / .changes *supposedly* uses utf8 natively. Heck, MultiByteFileStream>>setConverterForCode uses MacRoman unless you've written the utf8 BOM-marker ... Use MultiByteBinaryOrTextStream>>setEncoderForSourceCodeNamed: , and it WILL use MacRoman for .cs or .st files no matter what the streams contents are (thankfully, there are no senders in the core image, at least) Which is weird to me, since ByteString encoding is assumed to be 8859-1, and the default fonts displays 8859-15 characters :) Change any of this however, and you will surely break some old filed-out code. TLDR; There is no overall strategy for ensuring that code will be saved externally in a unicode-compatible encoding, and it's probably impossible to implement one while maintaining backwards-compatability. If you want to stay safe, use only ASCII. If you plan to never export any code (say, use changesets or Monticello), write in whatever language you want. (well, as long as you are able to input the characters of course) Cheers, Henry
It would be nice to clean that situation in 1.3 I think that we should get some tasks and tackle it together. Probably more pair programming would help. Stef On Jul 29, 2010, at 10:42 AM, Henrik Johansen wrote:
On Jul 29, 2010, at 9:23 54AM, Philippe Marschall wrote:
On 07/28/2010 10:48 PM, Alexandre Bergel wrote:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Are you sure all your subsystems (changesets, fileouts, changes file, Monticello, ...) are Unicode aware? Do you use Unicode normalization? If so which one?
Cheers Philippe
+1. Venture outside the ascii-range, and you are asking for trouble when storing code externally. AFAIK, only the .sources / .changes *supposedly* uses utf8 natively. Heck, MultiByteFileStream>>setConverterForCode uses MacRoman unless you've written the utf8 BOM-marker ... Use MultiByteBinaryOrTextStream>>setEncoderForSourceCodeNamed: , and it WILL use MacRoman for .cs or .st files no matter what the streams contents are (thankfully, there are no senders in the core image, at least) Which is weird to me, since ByteString encoding is assumed to be 8859-1, and the default fonts displays 8859-15 characters :) Change any of this however, and you will surely break some old filed-out code.
TLDR; There is no overall strategy for ensuring that code will be saved externally in a unicode-compatible encoding, and it's probably impossible to implement one while maintaining backwards-compatability. If you want to stay safe, use only ASCII. If you plan to never export any code (say, use changesets or Monticello), write in whatever language you want. (well, as long as you are able to input the characters of course)
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 07/28/2010 10:48 PM, Alexandre Bergel wrote:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Are you aware that the whole concept of upper and lower case is locale dependent and some languages (Turkish IIRC) have different rules? Cheers Philippe
+ 20000 Stef On Jul 28, 2010, at 10:27 PM, Juan Vuletich wrote:
Hi Folks,
I think that is a mistake. Having Spanish as my mother tongue, I used to code with Spanish names before knowing Smalltalk. So when started using Smalltalk I kept doing it. Later I realized it is a bad idea. In Smalltalk there is no clear distinction between the "vendor libraries" and our own code. Our application specific classes will many times implement methods akin to existing ones in the system. Writing their names in English makes the whole system more consistent. Following this a little bit, it is better if all the code we write is in English too.
OTOH, I believe it is ok to write comments in languages other than English (if the code will not be open sourced).
I'd even suggest the system to reject names and selectors not in ASCII.
Cheers, Juan Vuletich
Alexandre Bergel wrote:
I have no idea how to help you. But trying to have classes with chinese (or any other alphabet with accents) names is important. Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example.
Cheers, Alexandre
On 28 Jul 2010, at 21:33, empty wrote:
In 1.1 and 1.2, without setting a language environment for Chinese, I am able to use Chinese by setting fonts. It seems to work except for accepting a class named in Chinese will end in a ClassBuilder error of 'Class names must be capitalized'. Well is it a feature(requires language environment being set correctly) or bug?
The code located being:
validateClassName: aString "Validate the new class name"
aString isSymbol ifFalse: [ ^ false ]. aString first canBeGlobalVarInitial ifFalse:[ self error: 'Class names must be capitalized'. ^false]. environ at: aString ifPresent:[:old| (old isKindOf: Behavior) ifFalse:[ self notify: aString asText allBold, ' already exists!\Proceed will store over it.' withCRs]]. ^ true
and following the code the problemic method is #canBeGlobalVarInitial: which is found in two classes: in EncodedCharSet class side: canBeGlobalVarInitial: char
| leadingChar | leadingChar := char leadingChar.
leadingChar = 0 ifTrue: [^ self isUppercase: char]. ^ self isLetter: char.
and in LanguageEnvironment
canBeGlobalVarInitial: char
^ Unicode canBeGlobalVarInitial: char.
I didn't set a Chinese environment and the exception is occured in in EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought to be lowercased.
----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p230... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3030 - Release Date: 07/26/10 15:34:00
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (11)
-
Alexandre Bergel -
Carla F. Griggio -
csrabak＠bol.com.br -
empty -
Henrik Johansen -
Juan Vuletich -
laurent laffont -
Nicolas Cellier -
Philippe Marschall -
Serge Stinckwich -
Stéphane Ducasse