Yes I contacted Janko if he can fix that On Dec 24, 2008, at 5:25 PM, Damien Pollet wrote:
> 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 do not think so but what would be good is to be aware of shadowed or used and not there variables because when you integrate code like we did and mike too. Shadowing is a plague because you do not know the code this is not yours and silently the compiler compiles and you have broken code but you do not do it. Dynamically typed does not weak. > > >> 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) Yes I think that this is the way to go Something like deprecated. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
