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