[cp-patches] Patch: FYI: implement NumericShaper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 On Sun, 2006-03-19 at 19:58 -0500, Stuart Ballard wrote:
> On 3/19/06, Andrew John Hughes <gnu_andrew@xxxxxxxxxxxxxx> wrote:
> > I think the interface problem you mention is the most obvious, but I
> > think this should be solvable by declaring the class abstract (which
> > shows up in JAPI too).
> 
> It's a shame that we can't use annotations on the trunk; it wouldn't
> be hard to have Japi pick up an annotation which marked stub methods
> and flag any such methods as errors.

I agree.  Of course, we also really need a command-line tool for them
too.

> 
> What's the status on the whole ecj-as-gcc-frontend thing? Since gcj
> and ecj are pretty much the only maintained Free java compilers at
> this point, seems to me that's the only blocker to making the generics
> branch the primary development trunk and adopting the new language
> features wholesale...
> 

I'd be interested to know this, especially as to whether this can be
done before GPLv3 becomes a reality.

> I also remember hearing about some stub methods in Swing which are
> currently defined as calling super.whatever(), which will eventually
> need to be overridden but currently other features in the class do
> work. 

If it's the one I'm thinking of, it's fixed in gcj 4 which we now
require.

> Declaring the class as abstract would break working
> functionality; deleting the stub wouldn't have any effect on the japi
> results because the inherited method would be picked up.
> 
I'm only thinking about this for interfaces, where e.g. part of the
interface is implemented, the rest is stubbed.  You remove the stubs,
and declare the rest abstract so it will at least compile (and be
comparable).  Yes, it will break functionality, but that's an incentive
to fix the rest of it... Presumably, japi would pick that up as a
concrete/abstract difference and for each of the missing methods.
For anything else, they should be removed.

> As far as I can figure out, an annotation is pretty much the only way
> to get these kinds of methods to get flagged by Japi.
> 

We could do this on generics.  I already find 1.5 comparisons pretty
useless for HEAD, because it will never be able to implement all the
language features (and will have differences).

> Stuart.
> 
> --
> http://sab39.dev.netreach.com/
> 
-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

If you use Microsoft Office, support movement towards the end of vendor
lock-in:
http://opendocumentfellowship.org/petition/

"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman

Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://developer.classpath.org/pipermail/classpath/attachments/20060320/9a32e11d/attachment.pgp

[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux