I am inclined to agree but isn't there another better solution. Seems like there mist be but maybe not
Sent from my iPhone Michael McGrady Principal investigator AF081_028 SBIR Chief Architect Topia Technology, Inc Work 1.253.572.9712 Cel 1.253.720.3365 On Dec 17, 2010, at 8:09 AM, Tom Hobbs <tvho...@googlemail.com> wrote: > I think the difference between generics vs not-generics in this case > is to do with expectations. > > If generics are used on the method signature then the client developer > *expects* not to encounter any runtime issues. In certain > circumstances this expectation is incorrect. > > The method signature without generics forces the client developer to > do a runtime check and a cast. This is the only way to be safe in all > cases. Of course every developer does a type check before they cast, > don't they? ;-) > > I think this (no generics) is the correct approach for Outrigger, > because it places 100% of the enforcement of this kind of safety on > the client developer. That may not be the most convenient thing for > all developers, but it prevents a potentially difficult bug hunt > trying to work out why a cast failed when the developer is convinced > that it's the correct type - and the use of generics "proves" that > it's the correct type... > > On Fri, Dec 17, 2010 at 3:58 PM, Wade Chandler > <hwadechandler-apa...@yahoo.com> wrote: >> >> >> ----- Original Message ---- >> >>> From: Peter Firmstone <j...@zeus.net.au> >>> To: river-dev@incubator.apache.org >>> Sent: Fri, December 17, 2010 7:02:26 AM >>> Subject: Re: Space/outrigger suggestions >>> >>> jgr...@simulexinc.com wrote: >>>> public Entry read(Entry template, Transaction txn, long timeout); >>>> >>>> That is indeed the original/current method's signature. >>>> >>>> A couple of points. >>>> 1) "The client knows the []'s class type, the class cast isn't much work" >>>> is >>> an argument against all generics, not just generics in this case. >>> >>> >>> >>>> It ignores the additonal specification power and type safety that the >>> generic provides. >>> >>> This is a very important comment, as it reflects the common understanding >>> developers have of Generic's, this is true for code at compile time, >>> however >>> Java's generic implementation suffers from erasure, the type safety >>> disappears >>> after compilation and relies on the fact that the code has been audited by >>> the >>> compiler. >>> >>> The binary signature of your method is the same as it is in bytecode now, >>> adding generic parameters won't change the binary method signature. >>> >>> It is unfortunate that your example will work with generic's, which is >>> due to >>> the template being passed as a parameter, restricting the return type to >>> matching that of the template, the problem is, people don't understand why >>> this >>> works and just assume that generic's will work in all cases for distributed >>> programming, then start using generics in their service api, it will work >>> at >>> first, but at some point in time, separately compiled code will be mixed, >>> the >>> class cast's won't have been checked by the compiler, then they'll get >>> burnt by >>> class cast exceptions, after deployment, the worst time to catch the >>> problem, >>> hence my comment, the type cast is simpler if performed by the client, >>> where it >>> can be checked at runtime. >>> >>> The type casts weaved into bytecode by the compiler are checked at compile >>> time, by the compiler and are not checked again at runtime. These checks >>> are >>> not performed in code that has been compiled separately. >>> >>> Check out Jim Waldo's book: >>> >>> http://www.amazon.com/Java-Good-Parts-Jim-Waldo/dp/0596803737 >>> >>> See also: >>> >>> http://gafter.blogspot.com/2006/11/reified-generics-for-java.html >>> >> >> That taken into account, the proposal does make things better and works. >> Sure, >> there are some gotchas with generics, but you have to go on a case by case >> basis. Making something simpler makes a heap of sense, and in this case, it >> works well. I don't see the down side to this request. The same argument here >> can be made for the cast. The client is assuming it is this "type" so they >> cast. >> Same with the generics. The client assumes it is this "type" which they are >> programming into the case...lookup this type with this template. Were there >> some >> runtime mishap it would affect it just the same. Just using a cast doesn't >> ensure anyone builds in some extra safety which will some how work around >> that >> issue. Am I missing something else about this proposal? >> >> Thanks, >> >> Wade >> >> ================== >> Wade Chandler >> Software Engineer and Developer >> NetBeans Dream Team Member and Contributor >> >> http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam >> http://www.netbeans.org >> >>
