Re: suggestions for newbee

> The goal of the following suggestion  is to enforce some coding
> convention at the nice compilater level : 
> * remove 'var' and 'let'. If 'let' is to define constantes (!= 
> immutable) then every constantes have name in uppercase (only), and 
> variable start by lowercase. Compiler could automaticaly detect this and 
> choose internaly between 'var' and 'let' rules.

One of "standard" Java conventions state that global (aka static) 
variables should have an all-uppercase name. I found this convention to 
be a sound one - makes easy to differentiate global variables from local 
ones, especially in Nice, where global variables can be defined on 
package level. Instance variables can be differentiated by always 
prepending a local instance variable to them, like "this.someVariable", 
or better "someInstance.someVariable" (becouse this can be ommitted, 
while someInstance can't be omitted). Example:

class SomeClass { String someVariable; }
// someInstance is used *instead* of "this".
void doSomething( SomeClass someInstance ){
   let len = someInstance.someVariable.length();
   // do something else...
}

This makes difference between local and instance variables very clear.

About your suggestion of using all-uppercase names for "final" 
variables, from my experience it wouldn't be convenient: i usually use 
"let" everywhere to somewhat protect local variables from accidental 
modification in the later code, and to make the code more clear (it is 
simpler to read the code if we know that this particular variable will 
not be reassigned). Then if i need to reassign the variable, i simply 
change "let" to "var". In your scenario i must somehow replace lowercase 
variable with all-uppercase in the whole method. And what if there is 
already an all-uppercase global variable with the same name?

> * Why 'Type Inference' isn't systematic, and can't be use for arrays ? 
> Could you give me samples ?

What do you mean it "isn't systematic" ?

> * Why do you choose to allow multiple class declaration in one file ? 

I'm not the author of the Nice language, but i suppose:
a) becouse of multi-methods, global methods, anonymous methods and 
multi-dispatch;
b) becouse class location is a question of application design (Package 
and Deployment diagrams in UML, for example);
c) becouse having multiple classes in a single source is a way of 
allowing "friend" visibility relations between them;
d) becouse in object-oriented languages it is really unpractical to have 
a separate file for each class, which Java solves with inner and 
anonymous classes.

I liked the Java way at first, too. But later i found i have troubles 
creating classes, becouse i need a separate file for each class, even 
for minor ones. This eventually leads to "thick interfaces".

> So the suggestion is for the nice compiler to define the package from the directory hierarchy

This might be done. But it is a good safety constrain. I had situations 
when i targeted Nice compiler to the wrong directory. Should nicec 
silently compile 'src.ru.glim' instead of 'ru.glim'? Package definition 
might also help the compiler to find sources when it have multiple 
source locations to look at. At least package definition should be left 
as an optional constrain.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click