On Wed, May 31, 2000 at 04:16:09PM -0700, Perrin Harkins wrote:
> Maybe I'm just being thick, but if you leave out the event driven parts of
> the spec, what's left that isn't just an ordinary Perl class? You can
> easily make classes to hold data using Class::Struct or
> Class::MethodMaker.
In all this time, I don't think I've seen you simply being thick even
once. :) I agree, if you take out the event driven stuff, beans
aren't that exciting. They are basically just property bags with a
way to reflect over those properties. However, if I build the
beginning of the bean model in Perl, then someone might come along and
add the event model.
> Is it just that you want a safer way to do introspection than looking at
> the data structure the class is made from? Maybe you want the
> Class::Fields module from CPAN.
Trust me -- this has nothing to do with "safe." :) The bean model is
simply a convention -- if a class has a getFoo and a setFoo, then it
has the property Foo. Like I said, I don't want to debate whether or
not it is a good standard. The entire point is to have a consistent
framework between Java and Perl. Chances are, the underlying
mechanism for doing the reflection will leverage something from the
Class:: package.
There are a million ways I'd rather see this solved in Perl. Or in
Java for that matter. But java.beans are pretty popular, and they
provide the underpinnings for EJB, which, for better or for worse, is
very prevalent in e-commerce. I'd rather support a mediocre standard
then invent a proprietary one. And beans aren't *that* mediocre.
-DeWitt
