Just for the record, Java compiler enforces code conventions like uppercases and so... but is configurable, usually you get a warning. You can change compiler configuration so it can throw an exception and you can tell him to ignore it (wich is what I do allways before starting a project, not because I break the rules, just because I hate to see the compiler telling me about other packages who break them... all the time)
IMHO, Lukas is right, it is not a problem of the compiler, but Lint... but if others prefer the compiler to do such tasks, I think java approach is not so bad: having three states configuration and defaulting them to warning (no error). Cheers, Esteban On 2008-12-24 12:13:56 -0200, Alexandre Bergel <[email protected]> said: > 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
