Re: myWishList

Hi Tom,

> I also have a few wish list items for nice.
> First I think it would be better if multimethods had a more normal 
> syntax. IE: Outside of a class I could declare:
> 
> int Object.toInt() throws NumberFormatException
> {
>    Integer i = Integer.decode(this.toSting());
>    return i.intValue;
> }
> 
> Then this would add a function to the object class. 

Hum, so you're suggesting Object.toInt() instead of toInt(Object this). Why 
not, but is it really clearer from a Java background? Both are somewhat close 
to Java, but of course slightly weird at first, as multi-methods are really a 
concept that does not exist in Java.


> It would be also 
> good if this function would be included in JavaDocs/NiceDocs. 

Yes, isn't it already?

> The 
> hardest part would be how to handle includes... I guess it would get 
> imported if you import the class of the name of the file it is attached 
> to...

Nice works at the package level for this. Methods belong to packages, and they 
are available if the package is imported.


> Another thing I would find really useful is to somehow get the benefits 
> of macro preprocessing. 

...

> In the logger class, I change the debug function to read:
> 
> //Keyword inlineable means this function will get inlined into it's caller.
> inlineable void debug (expression<String> expr) throws Exception
> { //expr is a valid java expression that will evaluate to a String.
>    if(shouldlog(Levels.DEBUG)
>    {
>        logThis(expr); //Only now is expr evaluated. Because we know it 
> returns a string, it can't cause problems.
>        //We have to throw or handle an exception because expr could 
> throw one.
>    }
> }
> 
> Then the caller would just do:
> logger.debug(expenciveFunctionCall());

You can basically do this already with anonymous functions:

void debug (()->String expr)
{ //expr is a valid java expression that will evaluate to a String.
   if(shouldlog(Levels.DEBUG)
      logThis(expr());
}

Then the caller would just do:
logger.debug(()=>expensiveFunctionCall());

Of course it could be nice to be able to omit the ()=> at the call site. This 
would be possible to do it if we added a typing rule T subtype of ()->T (which 
we could call lazy<T>) and an associated generation of a closure (which is 
already implemented for ()=> ...).


> I don't have a lot of time available, but I do know Java well, and would 
> be willing to help implement this.

Thanks! If there is agreement about this feature, then don't hesitate to 
contact me, nice-devel or the irc channel for help to get started.

Daniel



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