On Wed, Dec 24, 2008 at 15:13, Alexandre Bergel <[email protected]> wrote: > I do not think that a preference should relax some static language > enforcements.
Rule of thumb: if you just thought "maybe a preference would fix that…" then you're avoiding the real problem :) I think the initial concern of Lukas is that it's a practical burden to him if Pharo becomes too restrictive to load Seaside. So either there is Swazoo and a couple other easy problems, and they should be fixed quickly, or it's too much work to do the fixes and the compiler should stay a bit permissive for the moment. Or Seaside doesn't work on Pharo for some time. So I agree the conventions should be documented and breaking them discouraged, but in practice it's probably more valuable to have Seaside loading nicely than to have nice code NOW, and handle the problem with a transition period like with deprecated methods. > 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. Also in Ruby: $global @instVar @@classInstVar …and in Java: int anInteger; Yes, enforcing is like static typing, and Code Critics is like pluggable type systems :) > Forbidding a new value to be assigned to a method variable is a simple > increase the readability. Why ? they are defined once at the beginning of the method, just not between the | |; I think of them as locals that just get initialized to something else than nil… Now maybe I don't see the problem because I'm not used to C so it wouldn't even occur to me that assigning to parameters could have an effect on the caller. > 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. Huh, do you really want to use :each1 :each2 :each3 if you have three loops in the method ? > As a follower to that line, something that would be great to have, is > to forbid accesses to an undefined variable. What if you remove the variable definition from the class ? Do you want the compiler to force you to remove all uses immediately ? > 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. Sure, but we could try to make the transition easier (e.g., complain to Janko for the moment and wait until Pharo stable to enforce conventions) > 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 > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
