On Dec 23, 2008, at 10:25 PM, Lukas Renggli wrote: >> Can you tell me which one so that I ask Janko to fix it? > > It is the class instance-variable Singleton in SwazooBenchmarks. > >>> Unfortunately Pharo throws a notification >>> (instance variables should begin with a lower case characters) when >>> loading that code. >> >> May be we should have a way to trap that exception. > > I don't think this will be the only problem we encounter. I reported > this issue, because I am afraid that Pharo makes porting unnecessary > hard and unnecessarily restricts the language.
Sure please continue this is important to learn from that. >>> - class names and class-variable names are enforced to be uppercase >>> - class instance-variable names are enforced to be lowercase >> >> I really think that this is good. >> Else what is the point to have a syntax? > > This is not part of the Smalltalk syntax. The syntax only says that a > variable is a letter followed by zero or more letters or digits. But the books I read were really mentioning that the uppercase indicated scope. lower private upper global. I thought it is rather cool to have such conventions that are ready standing out. And this can be part of the syntax of a language. Why Smalltalker wants always not to care. A bit of regularity does not hurt. Then in that case why Class name do not start with lowercase and instance variables with Uppercase if the compiler allows it then this is cool let us use it. >>> - it is not possible to assign a new value to a method argument >> >> This was always like that in Smalltalk. Arguments are ready only. > > I am just giving examples, this was discussed before. > > Since arguments are exactly the same as temps, this is just something > the compiler is enforcing on us. Being able to assign to arguments is > extremely useful and makes code much easier to read. Almost all todays > programming languages (C, C++, C#, Java, Ruby, JavaScript, ...) allow > that. I may be wrong but I imagine that this has some impact on the produced byte code and probably Jitted code too. > > >>> - variable names are enforced to be unique in all scopes >> >> This is the limit of the current compiler and not having full block >> closure I imagine. > > What I ment was more the fact that it is not possible to give a > temp-var the same name as an inst-var of the owning class. I think that this kind of shadowing is really not a good idea. In VisualWorks you can do it and I really would hate code written that way because I would always have to keep in mind that only on certain methods the variable I see is not the instance variable of the object but a local You could argue that since you redefine the variable you know it and this could work because we have small methods but with code longer than a page it can be leading to bug. > Or an > inst-var the same name as a global-var. How this is possible since a global should be uppercased and a instance variable lowercase? > Again, most todays programming > languages allow that. This is an unnecessary restrictions. Can you show us a case where this is useful? in ambientalk I could be convinced but ambientalk as block srtucture (nested object). In languages with block structure it is convenient but in Smalltalk with its flat structure I do not see why this is so important? (C, C++, C#, Java, Ruby, JavaScript, ...) they do not have the same program structure than Smalltalk program. In VisualWorks you can have block argument having the same name as instance variable now it is really good? This means that you cannot access the instance variable from the block internal directly. Ok you can you use a self send. Now I think that using the same name for two lexically different variable is not really cool. >>> In my opinion the language should be as open as possible. >> >> No it should follow well specified rules. Else this is the mess. >> In Smalltalk uppercase are for global variables and lowercase for >> private. > > Anyway, we don't have to agree on Smalltalk in general ;-) > > The only problem I have right now is that Seaside with Swazoo doesn't > load into the latest Pharo, because the compiler disallows uppercase > class instance-variables. It is not an unsolvable problem, but we have > to figure out a nasty hack to make the load-script silently load the > code. And the maintainers of Package Universe and Monticello > Configurations will have to figure out similar patches to work around > the Pharo Class builder. I think that we should have a preference to deal with that. > > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
