Pharo 1.1/1.2 and class names in Chinese
Locked
 
|
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.
南無佛 南無法 南無僧
|
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
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-tp2305496p2305496.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
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-tp2305496p2305496.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
> 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-tp2305496p2305496.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
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 "addIndice:" 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 <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
In reply to this post by Alexandre Bergel
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 <[hidden email]>: >> 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-tp2305496p2305496.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
2010/7/28 Nicolas Cellier <[hidden email]>:
> 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 <[hidden email]>: >>> 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-tp2305496p2305496.html >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
In reply to this post by Nicolas Cellier
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 <[hidden email]> wrote: Once upon a time I wondered if it wouldn't be possible to translate _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
2010/7/28 Carla F. Griggio <[hidden email]> Well, that last comment reminded me of something: 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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
In reply to this post by Alexandre Bergel
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
In reply to this post by Alexandre Bergel
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
In reply to this post by Philippe Marschall-2
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
In reply to this post by Philippe Marschall-2
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by laurent laffont
Em 29/07/2010 03:10, laurent laffont < [hidden email] > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
On Fri, Jul 30, 2010 at 1:29 AM, <[hidden email]> wrote:
> > Em 29/07/2010 03:10, laurent laffont < [hidden email] > 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/ _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Em 30/07/2010 01:12, Serge Stinckwich < [hidden email] > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
In reply to this post by Juan Vuletich-4
+ 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-tp2305496p2305496.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo 1.1/1.2 and class names in Chinese
|
|
In reply to this post by Henrik Sperre Johansen
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |