Re: Re: suggestions for newbee

Artem Gr wrote:

>> 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.


I agree that differentiate local and instance variables is great (in 
java, I use naming convention instance variable's name end with '_'), 
but someInstance.someVariable and declare someInstance in the method 
signature isn't very "lazy typing". In python , I dislike repeat "self" 
in every method signature and definition. I thing a one caractere would 
be better. may be something like '.' prefix (implicit this) so your 
sample in a file SomeClass.nice (following my next suggestion)  give :
// SomeClass.nice
String someVariable;

void doSomething() {
  let len = .someVariable.length();
}

Note I also like the indentation rule (no braces, no semi-colon) of 
Python, after one day of "figth".

>
> 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?
>
If "let" is like "final" in java, it doesn't "protect local variables 
from accidental modification", it only protect against reassign. It's 
possible to call method on the "variable" that change internal state. Du 
to this "bad friend", I don't use "final" in java method, So it's why I 
forgot this case. I use only final for constante (enum, or immutable 
object), or for readonly instance field (replace by Propety in Nice). 
I'll think to a more precise suggestion (like let + immutable <=> 
Constante <=> UPPERCASE).

>> * 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" ?


Type is *optional* with "let", "var", and nice accept Java style for 
"local" variable. May there is a justification (like in Boo) for when 
Type must be specified (e.g Type is an interface). May it's just a 
comments to add in the manual.

> * 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;

Sorry I don't understand.

> 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;

"friend" isn't exists in Nice, isn't it ?

> 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 don't agree see (my other reply). several class in one file is 
practical only for little application or project with one developper. 
It's a problem for Python where it's also possible. And Python has a 
Coding Convention Proposal to avoid this, but can't force it into the 
language due to compatibility.

> 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".

I agree with you I use a lot for "struct" (inner or not) but it's 
difficult for co-develloper, and promote the creation of duplicate Class 
(helper, inner struct,...) in big project where developper don't know 
every classes (only take an overview of first level classes).

>
>> 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
> _______________________________________________
> Nice-info mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nice-info



-- 
--------------------------------------------------------------
David "Dwayne" Bernard             Freelance Developer (Java)
                                   mailto:[email protected]
      \|/                          http://dwayne.java-fan.com
--o0O @.@ O0o-------------------------------------------------



-------------------------------------------------------
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