- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Philippe Marschall

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

July 29, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by laurent laffont

2010/7/28 Carla F. Griggio <carla.griggio(a)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(a)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(a)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-tp2305496p23… >> >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >>>> >> >>>> _______________________________________________ >> >>>> Pharo-project mailing list >> >>>> Pharo-project(a)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(a)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(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

Re: [Pharo-project] help with Glamour

by Tudor Girba

Hi Felipe, The result of opening a browser is a window. So, you could use something like this: browser := GLMTabulator new. ... window := browser openOn: ... window maximize. ... window delete. Could I ask in what context you are using Glamour? Also, a better forum for discussing these issues is the moose-dev mailing list: - address: moose-dev(a)iam.unibe.ch - registration: https://www.iam.unibe.ch/mailman/listinfo/moose-dev Cheers, Doru On 28 Jul 2010, at 21:04, Alexandre Bergel wrote: > Hi Felipe, > > No idea, but this is good to see you here! > > Alexandre > > > On 28 Jul 2010, at 18:47, Felipe Ignacio Valverde Campos wrote: > >> Hi, i'm beginner on this tools, so i need your help please :) >> i have some doubts about Glamour, specificaly with GLMTabulator. >> >> how can i set the window size ? >> and how can i close it without pressing the X ? >> >> thanks >> -- >> http://www.dcc.uchile.cl/~fvalverd/public_key.asc >> Estudiante de IngenierÃa Civil en ComputaciÃ³n. >> Facultad de Ciencias FÃsicas y MatemÃ¡ticas. >> Universidad de Chile. >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Reasonable is what we are accustomed with."

July 29, 2010

Re: [Pharo-project] Books for summer (was: Time Machine)

by laurent laffont

On Wed, Jul 28, 2010 at 11:45 PM, <csrabak(a)bol.com.br> wrote: > Em 26/07/2010 02:39, laurent laffont < laurent.laffont(a)gmail.com > > escreveu: > > > > And you dear Pharoers, what will you read this summer regarding > > your computing/business activity ? > > > Laurent, > > I'll wait until summer arrives then I'll report back ;-P > :D Should I change the subject to "Books for winter ?" Laurent > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

[Pharo-project] Magma on 1.1 one click image

by Ramiro Diaz Trepat

Hi fellow pharoers, Magma fails to load from the commands on the Pharo 1.1 workspace. In my oppinion they should be removed from the that workspace, it gives users a sloppy impression of the release. I don't think the image has to be sacred and untouched, we can remove 5 lines from a workspace, it will be good for Pharo 1.1. Aside from that minor detail, I am enormously happy and grateful to all for this release. Cheers r

July 28, 2010

Re: [Pharo-project] Books for summer (was: Time Machine)

by csrabak＠bol.com.br

Em 26/07/2010 02:39, laurent laffont < laurent.laffont(a)gmail.com > escreveu: > And you dear Pharoers, what will you read this summer regarding > your computing/business activity ? > Laurent, I'll wait until summer arrives then I'll report back ;-P

July 28, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by 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 :( On Wed, Jul 28, 2010 at 6:32 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)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(a)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-tp2305496p23… > >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >>>> > >>>> _______________________________________________ > >>>> Pharo-project mailing list > >>>> Pharo-project(a)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(a)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(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 28, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Nicolas Cellier

2010/7/28 Nicolas Cellier <nicolas.cellier.aka.nice(a)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(a)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-tp2305496p23… >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)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(a)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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 28, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Nicolas Cellier

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(a)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-tp2305496p23… >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 28, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Carla F. Griggio

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(a)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-tp2305496p23… > >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 28, 2010