Re: myWishList

--- Daniel Bonniot <[email protected]> wrote:
> 
> > nice documentation (classification: eccentric,
> > priority: medium, difficulty: low) { 
> > why would anybody write a comment other than for
> > documentation purposes?
> 
> For instance, commenting out a piece of program
> (class, method). If there was 
> only one type of comment, nicedoc would not be able
> to make the difference 
> with real documentation.

in short, what I am saying is, ... keep /* */ for
commenting... like commenting out some code, keep //
for comments inside methods, banish /** */ and replace
them with // outside the method for documentation. the
only real restriction here is this: inside methods, //
and /* */ both mean comments. outside, if you want
comments, you have to use /* */. why banish /** */? no
particular reason... erm... but did you notice the
nicedoc keywords I proposed? @returns rather than
@return, @is instead of @param to make it more
readable? it's all trivial, really. don't bother.

> > static import (classification: obvious, priority:
> > high, difficulty: low) { 
> > import static my.Constants; 
> > lets you use all the static methods and fields
> without
> > question. 
> > }
> 
> I agree we should probably have it for
> compatibility's sake. But is this the 
> Java 5 syntax?
> Would you care to open a RFE?
> 

I think so... this is Java 5 alright..

> 
> > abstract interfaces (classification: disastrous,
> > priority: medium, difficulty: high) { 
> I agree this would be natural syntactic sugar for
> 
>    class java.util.Vector implements
> MonsterWithATail;
>    last(Vector this) = elementAt(size() - 1);
> 
> Another RFE!

well... that's all it! syntactic sugar,..
> 
>  > moreover, I see no semantic difference between an
>  > ordinary interface and an abstract one. the very
>  > distinction undermines the true value of abstract
>  > interfaces.
> 
> There are compilation and typing differences. For
> compilation, you have to 
> understand that making a class (like Vector)
> implement an interface after the 
> fact is just not supported in java bytecode. This
> means that we can only do it 
> for special, "abstract" interfaces that do not
> appear at the bytecode level. I 
> don't think it is generally possible to detect
> automatically which interfaces 
> should be abstract without breaking separate
> compilation.

that makes sense.

> > and no method should appear outside such clearly
> > defined boundaries. public interfaces still are,
> of
> > course, just Java interfaces. but this means you
> will
> > have to abandon the custom constructor syntax, and
> I
> > guess I am more than alright with that. it seems
> to me
> > that sacrificing the flexibility Nice offers right
> now
> > is too precious to give up and this is, I assure
> you,
> > the only thing I am asking for which goes directly
> > against the principles of Nice. still, think it
> over,
> > will you?
> 
> I don't understand: you think "the flexibility Nice
> offers right now" (methods 
> outside classes?) "is too precious to give up", but
> you seem to advocate to 
> give it up for the sake of clarity.

yes.




		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 


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