Re: About stub methods
On Tuesday 30 September 2003 11:04, Ingo Prötel wrote: > PS: obviously a bike shed on green grass should be grass green ;-) Isn't that a violation of grass semantics? And hoe are we supposed to tell the difference between a bike which leaning against the shed and one which has fallen on the ground? -- Chris Gray/k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: About stub methods
Hi Mark, this sounds like a good solution. And since I started this whole thing I will start going through the code and look for not or partly implemented methods. And many thanks for stopping this dicussion. --ingo PS: obviously a bike shed on green grass should be grass green ;-) Mark Wielaard wrote: Hi, Please Stop arguing about how the framework for handling unimplemented classes and stub methods should work. I know it is the ideal "What color should the Bike Shed have" discussion (*), but stub methods are a bad thing to have and should just be treated as grave bugs. Having those method because they allow people to compile against GNU Classpath but not run against it really doesn't make much sense. Let people fix either their code or help us implement the missing functionality. If you find such a method in the source please just remove it and file a bug report about it (possibly with as bug message the partial implementation). Or better just implement it! If there really is a strong reason to have that particular method as a stub method then we should do that in the simplest possible way that makes it easy to quickly find those methods in the source. That means that it should be some standard string that people can easily grep for all on one line. Note that as said above making things compile, but not run with GNU Classpath is not a strong reason. So you should really be able to point to a free software program written in java that would just need one little stub method to be completely usable with GNU Classpath to justify having something as a stub method. The first person to actually volunteer to go through more then a handful of classes to remove (silent) stub methods gets to decide what the actual "Not Implemented" line says (and whether it is an Exception or an Error, an existing class or a new class). Who actually want to do this work? And if whole classes or packages are stubby then we are better off just removing them or at least add them to the lib/standard.omit file so they won't appear in our release till we can offer real functionality for them. Thanks, Mark (*) http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: About stub methods
Mark Wielaard <[EMAIL PROTECTED]> writes: > If you find such a method in the source please just remove it and file a > bug report about it (possibly with as bug message the partial > implementation). Please leave the stub methods in java.awt.peer.*/gnu.java.awt/peer.*, thanks. Feel free to make them do whatever you'd like. :) Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: About stub methods
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 29. September 2003 22:43 schrieb Andrew Haley: > Mark Wielaard writes: > > stub methods are a bad thing to have and should just be treated > > as grave bugs. > > > > Having those method because they allow people to compile against > > GNU Classpath but not run against it really doesn't make much > > sense. Let people fix either their code or help us implement the > > missing functionality. > > > > If you find such a method in the source please just remove it > > and file a bug report about it (possibly with as bug message the > > partial implementation). > > Hey, hey. I could not agree more. I thought this would be a hard > thing for me to push, but it looks like I'd be pushing at an open > door. > > No more stub methods! A pox on them! Wow, I would have never thought that somebody could share my thoughts. In my beginnings of classpath and libgcj hacking I was a big fan of stubbed methods. But now I see that much methods can be stubbed easily and tools like japitools have a hard time to tell if the method is implemented or just a stub. I vote for no more stubs too. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/eKXVWSOgCCdjSDsRAkCJAJ9OXs27uAjFuiHfe+ojSETDd+WwPwCdEIeI muRpbxM4xz5UKVMjOZE5Cg8= =XRyM -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
About stub methods
Mark Wielaard writes: > stub methods are a bad thing to have and should just be treated as > grave bugs. > Having those method because they allow people to compile against GNU > Classpath but not run against it really doesn't make much sense. Let > people fix either their code or help us implement the missing > functionality. > > If you find such a method in the source please just remove it and file a > bug report about it (possibly with as bug message the partial > implementation). Hey, hey. I could not agree more. I thought this would be a hard thing for me to push, but it looks like I'd be pushing at an open door. No more stub methods! A pox on them! Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
About stub methods
Hi, Please Stop arguing about how the framework for handling unimplemented classes and stub methods should work. I know it is the ideal "What color should the Bike Shed have" discussion (*), but stub methods are a bad thing to have and should just be treated as grave bugs. Having those method because they allow people to compile against GNU Classpath but not run against it really doesn't make much sense. Let people fix either their code or help us implement the missing functionality. If you find such a method in the source please just remove it and file a bug report about it (possibly with as bug message the partial implementation). Or better just implement it! If there really is a strong reason to have that particular method as a stub method then we should do that in the simplest possible way that makes it easy to quickly find those methods in the source. That means that it should be some standard string that people can easily grep for all on one line. Note that as said above making things compile, but not run with GNU Classpath is not a strong reason. So you should really be able to point to a free software program written in java that would just need one little stub method to be completely usable with GNU Classpath to justify having something as a stub method. The first person to actually volunteer to go through more then a handful of classes to remove (silent) stub methods gets to decide what the actual "Not Implemented" line says (and whether it is an Exception or an Error, an existing class or a new class). Who actually want to do this work? And if whole classes or packages are stubby then we are better off just removing them or at least add them to the lib/standard.omit file so they won't appear in our release till we can offer real functionality for them. Thanks, Mark (*) http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
