On Fri, Oct 2, 2009 at 10:11 AM, Patrick LeBoutillier <patrick.leboutill...@gmail.com> wrote: > Choosing to always give objects the return types of the methods that > returned them would break a lot of things, > and would actually introduce more casting (i.e. anytime you would work with > generic containers, like Vectors, you > would always need to cast (just like in Java basically)). That in my opinion > would remove some of the "magic"...
Yeah, I can see that side of the issue too. Most of the stuff I've had to work around has been stuff surrounding interfaces for similar but slightly different reasons. For instance, when dealing with EJB, you have the same kind of problems. You look up a resource in jndi, you get back a portable remote object (the primorial object type for ejb) and have to narrow the cast based on an interface. When you get right down to it, its corba roots show pretty clearly. So, I did what seemed best. I encapsulated all that casting in a perl object facade for the ejb and presented a more perlish interface to calling code. Keep java looking like java, perl looking like perl and glue code as out of the way as possible :) The JDBC thing is kind of a different issue. For JDBC, there's a very clear distinction. JDBC is all about interface, not implementation. Initially I was thinking that it would be as simple as adding a little extra meta info about classes. Using reflection, you can pretty easily see what the return types of any given methods are. The issue, as you correctly point out, is that when you're dealing with concrete implementation classes, you can't really derive if a person is calling them from the context of an interface, or in the context of a plain old object reference. In some cases it would just result in a bunch of wasteful casts. > And because all overridden Java methods are virtual, meaning you can't > really call the wrong method when it's overridden > (unlike C++ I think), in reality this only seems to be a problem in these > specific circumstances: non-public classes that implement public interfaces > or extend public base classes. > Agreed. And there are other ways to work around the issue outside of Inline::Java. What we're running into issues with are a vendors implementation of the interfaces. I'm happy to give it a shot. Send me a patch, git url, svn url, or a tarball. I can test it out with mysql, oracle and probably a couple other databases if I force myself to make the time. I'm glad for the discussion, I'll see if I can come up with some patches for JDBC.pm that'll let it be a little more strong handed about forcing the interface casts. -- J.
