These are well-spoken arguments that Paul has below this post. Did it kill
the thread as I haven't seen any posts on this subject since? :)
In any case, while I agree with all these arguments, I also disagree. :)
I think it depends on the level you are talking about. If Brian creates
Servlets in Perl, I really kind of expect the API to remain the same as
Java as much as possible. Likewise, if we call something PNDI instead of
JNDI, I expect the API to remain the same as JNDI if the purpose is
interoperability of API.
The thing about beans though is that I don't know if I call it an API as
much as a lower level feature of the language. Yes, it is a feature that is
artificially constructed on top of already existing bytecode in Java, but
it is a pervasive framework about how an object should be coded as opposed
to an API.
I guess to me, the bean framework is a fairly low level extension of what
it means to be an object in Java except that it has some strict conventions
for attribute getting and setting and reflection. I don't see this being
overly different in Perl... UNLESS...
We actually come up with an API that is more than what Java beans are. I
think this is conceivable. If this is the case, then we would be
introducing something very different into the system that deserves it's own
name.
Let's say we change the name of Perl Beans to Pearls. If this is the case,
then an appropriate analogy is an Oyster project for a Enterprise Pearl
Container. That makes it just like Java Beans but with different names. So
this sounds disappointing to complicate the world with more names.
However, if we introduce an interesting feature to a Pearl ... that of a
PearlString to support a sort of "Aspect" or "Context" oriented programming
built into the concept of how Pearl's are coded to a strict interface, then
voila, we've come up with a concept more powerful than beans and so we
break the mold quite a bit.
eg A PearlString would be something like a context such as a
DebuggingPearlString which you string Pearl's on if you want them to be
debugged or traced in some way.
Anyway, I guess I can see both sides of the story. If I don't see people
adding much to the Bean API other than basically being a copy of Java
beans, then I am fairly disappointed about a new name. Imagine that it will
be a FAQ question on this list everytime someone joins it -- "What they
heck is this Pearl that everyone is talking about?" ... :)
I suppose if there are more creative thinkers than myself (the PearlString
is just one little idea) then I suppose it would be fairly obvious that our
version of "Pearls" is more powerful and so different from "Beans" that it
hardly then makes sense to call them beans.
Later,
Gunther
At 01:04 AM 11/19/2001, Paul Kulchenko wrote:
>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
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
