[nem-en] My thoughts on Nemerle

[Alejandro Serrano]

Michal Moskal escribió:

>On 1/8/06, Kamil Skalski <kamil.skalski at gmail.com> wrote:
>  
>
>>2006/1/7, Alejandro Serrano <trupill at yahoo.es>:
>>    
>>
>>>EXTENSION METHODS
>>>
>>>...
>>>      
>>>
>>After we have a macro (probably one attached to first parameter or
>>just method), which would add extension method to a class, these are
>>just cosmetic problems. We could easily have all the mentioned ways of
>>declaring extension method:
>>- public static foo (this s : string, ....)
>>- public static foo ([Extension] s : string, ...)
>>- [Extension] public static foo (s : string, ...)
>>- [Extension (string)] public static foo (...)
>>
>>Also making a class level macro, which would add the 'this xx : TYPE'
>>first parameter to methods in a class should be easy.
>>
>>What I like at most are first two (preferably second) ways of
>>specifying extension method.
>>    
>>
>
>The problem if we allow [Extension] on other than first parameter? Would
>this be compatible with extension methods in C# 3.0?
>  
>
C# 3.0 only allows extension parameters on first place, like the first 
example. Indeed, they just add an [Extension] attribute to both class 
and method, and substitute all references of this with this first parameter.
Maybe at some compiler stage (isn't there a stage where all types are 
inspected making a tree of methods?), we could add methods marked with 
[Extension] to the correct branch of the tree.
About specifying "this", the only problem I see is that then, on the 
method code, you have to substitute all references of this with the 
actual parameters, which I find really painful (and on my point of view, 
non-sense)

>  
>
>>>For extension methods use, I think the best way to go is to use "using"
>>>along with the name of the *class* (not namespace, as in C# 3.0) that
>>>contains the methods. Maybe some special "import" word can be used.
>>>      
>>>
>>Ah, this is one thing, which would require some additional effort in
>>implementation. I like your idea of requiring opening the class with
>>extension methods. It seems much more clean than the MS (One) way ;-)
>>    
>>
>
>I'm not sure: while this seems cleaner, forcing people to write ten more
>'using's in front of their file may not be that good idea.
>
>
>  
>
Maybe both?

>  
>
>>>NULLABLE TYPES
>>>
>>>I don't think it neccessary, although I wouldn't mind to see it. Should
>>>we use a more difficult typing engine only for getting nullable types? I
>>>really think not.
>>>      
>>>
>>Well, I'm quite neutral about nullable types. I never needed them in
>>Nemerle / C# yet, though I like the idea of convenient (at least as
>>convenient as in Java 5) wrappers for value types, so maybe adding
>>this additional syntax wouldn't be a bad idea.
>>    
>>
>
>I believe they are useful for static contract checking.
>
>  
>
>>>Buy maybe some things can be used:
>>>
>>>def f : float? = 3.0;
>>>
>>>for doing the conversion automatically, instead of:
>>>
>>>def f = Nullable(3.0);
>>>
>>>which I find stranger.
>>>      
>>>
>>Note that nullable types also have some special cases for typer, like
>>implicit conversions between T and T?. After I get used to this idea,
>>it seems quite nice.
>>    
>>
>
>Maybe this is just op_Implicit in Nullable[T]?
>  
>
Well, the problem is that not also we need to cast implicitly T to T?, 
and viceversa. We also need:
- (x == null) if x is a nullable type, means !x.HasValue
- x.Member means if (x.HasValue) x.Member else null
and so on.

I also fin useful to allow, in some Spec#-style, non-null parameters, so
method (T : string!) {
 ...
}

would mean

method (T : string) {
  if (T == null) throw ArgumentNullException();
  ...
}

		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y moviles desde 1 centimo por minuto. 
http://es.voice.yahoo.com