Hi, Gunther! --- Gunther Birznieks <[EMAIL PROTECTED]> wrote: > Well, I think copying a Java solution is doomed from a low level > technical > perspective because Java is a different language. But I think > coming up > with similar naming (if the conventions are similar) and honoring > what > actually was an excellent idea on the part of Sun by continuing to > adopt the name seems just fine to me. > > The other aspect is using similar interfaces. I think there should > be > little shame in coming up with interfaces that are fairly identical > to Java > as well as it will make stuff like SOAP much easier for > interoperability > between the languages. I could be wrong though. Paul would be the > expert there. While I agree with that my concern is that if it has name "bean" it should behave like bean (I would expect servlet in Perl to have exactly the same API as servlet in Java). I'm not absolutely sure that "bean" in Perl should/will replicate API of what is bean in Java because of differences in other related APIs, and even OO traditions.
Beans relate on persistence, introspection, event, component/bean and container APIs. will we be able to mimic Java API in all those aspects? I think answer is no. I'm not sure it's even feasible to do. As the result we'll have some concept that works like "bean" but it isn't bean, because it has slightly different API (although idea behind it it exactly the same or very similar). So, why don't give a different name that sounds/looks similar, yet is Perlish? I agree that marketing aspect is quite important and term "bean" is very familiar to many developers/managers, but still main idea is "what it does" rather than "what name is has". > While I think it is also OK to consider Perl it's own P5EE island, > I also > think part of the E for Enterprise means I for Interoperability. So > to some > degree this is why I like Brian's servlet API for Perl, and I also > am for similarity in terminology where appropriate. I'm for it, but interop for protocols is easier to get than interop for APIs. I can query object in Java using SOAP, yet our APIs to specify parameter and run SOAP server are absolutely different. But it doesn't hurt anybody. ApacheSOAP's API reflects Java traditions and SOAP::Lite's API is different, because it's Perl. There are definitely similarities, because they work in the same domain, but they are still different. I would expect the same thing to happen with bean API: same idea, but little bit different execution. > I think if we steal the Java convention and the basic idea behind > beans then why not just keep it called beans. Just because I will expect them to behave like beans. no less, no more. And you're bound forever. What if next version of J2EE add new methods or extend API? What if we need to add some methods/classes that Java's API doesn't have. IMHO we need to have "similar", but still different name. I'm open to change my mind ;) Best wishes, Paul. __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com
