[Pharo-project] On not unnecessarily closing down the language
alexandre at bergel.eu
Wed Dec 24 09:13:56 EST 2008
I do not think that a preference should relax some static language
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
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
On 23 Dec 2008, at 18:02, Stéphane Ducasse wrote:
> would a preference help?
> On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote:
>> Seaside depends on external packages, that we don't have control
>> 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 ...
>> Lukas Renggli
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Alexandre Bergel http://www.bergel.eu
More information about the Pharo-dev