I do not think that a preference should relax some static language enforcements. Contrary to Java, the Smalltalk community does not appear to be big enough to have these problem unsolvable.
I agree with Stephane, having a name that begins with a capitalized letter has a strong connotation of global visibility. And, on the contrary, an identifier beginning with a small letter has a restricted scope. Forbidding a new value to be assigned to a method variable is a simple increase the readability. Even if closure were supported, we should not allow a single identifier to appear as argument in different blocks in the same method. This does not help readability. As a follower to that line, something that would be great to have, is to forbid accesses to an undefined variable. I am aware that I am talking as someone who does not maintain cross- dialect applications, but we cannot trade readability for a local in time commodity. Alexandre On 23 Dec 2008, at 18:02, Stéphane Ducasse wrote: > lukas > > would a preference help? > > Stef > > On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote: > >> Seaside depends on external packages, that we don't have control >> over. >> >> For example there the Swazoo package contains a class-instance >> variable that is uppercase. Unfortunately Pharo throws a notification >> (instance variables should begin with a lower case characters) when >> loading that code. This is awkward, because it makes it impossible to >> load code automatically and gives us additional work. >> >> In my opinion a programming language should be as open as possible, >> and if possible not restrict the user in any way, even if this is >> against best practices. Unfortunately many of those restrictions are >> built into our language that wouldn't be necessary: >> >> - class names and class-variable names are enforced to be uppercase >> - class instance-variable names are enforced to be lowercase >> - it is not possible to assign a new value to a method argument >> - variable names are enforced to be unique in all scopes >> >> In my opinion the language should be as open as possible. It is the >> purpose of Code Critics to point out smells, not the task of the >> compiler to reject code that doesn't follow best practices. >> >> I am slightly frustrated trying to work around these restrictions ... >> >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
