Brett Ryan wrote:
> I don't think they are syntactic sugar, like I've mentioned previously
> a Property isn't simply a wrapper around getFoo/setFoo methods, they
> are a separate construct that does allow for type safety of some
> state. If you're a component designer and you come across a class with
> String getFoo(); void setFoo(Integer val) what do you do? Do you treat
> Foo as a single read-only property of String or do you not show it at
> all?__
>
I believe that's well defined by the JavaBeans spec. If not, it should be.
There's no reason that the getter/setter conventions from the JavaBeans
spec cannot be interpreted in just as type-safe a manner as some
official "Property" construct.
I will /not/ argue that the current state of affairs is anywhere near
perfect here in Java. For starters:
1. One should be able to use properties more directly in a type-safe
manner (e.g. via an -> operator)
* The Java compiler would understand JavaBeans as components
and do type-safe usage thereof -- rather than forcing one to
go through reflective APIs.
2. One should be able to communicate details to JavaBeans metadata
more easily, e.g. via annotations
> Properties are a 1-to-1 relationship of a classes member and the state
> it's representing, currently we don't have this support in Java.
>
Ack! 1-to-1 relationship with members?!? I have lots of classes where
this would be hugely inappropriate.
> Trying to traverse the object graph to find what members are
> properties is currently painful, I wrote an example the other day to
> explain to a friend this fact (attached), if you never have to write
> this sort of code then you're extremely lucky.
>
Why did you do this mess rather than just using the JavaBeans
Introspector? Generally if it does not answer the question I've found
that I don't need the answer -- but again I'm not claiming it is
perfect. Rather it should simply be improved as/where needed.
> Registering a listener in Java isn't the main problem, it's a real
> problem for a component author where you have to maintain a list of
> listeners, then call them when the event occurs. You end up with at
> least 15 lines of code, take a look at
> javax.swing.AbstractButton.fireActionPerformed(ActionEvent) as a
> classic example of this.
>
There should certainly be a better utility class than EventListenerList
at this point, yes, I'll agree 100%. This API is clumsy and obnoxious,
but that really argues for an API improvement in my book -- there's no
need for a language change to solve this problem.
> To properly get closures, you need function pointers, and that's why
> we need them in Java, and with function pointers we can implement
> proper events fairly easily.
>
Hmmm.... I don't actually see /anything /wrong with listener interfaces.
I see plenty of use cases for function pointers elsewhere, though --
albeit mostly in domains that overlap with closures.
> I don't want to assume, but are most people who couldn't care for
> events/properties server side developers? The real benefit to these
> features is with statefull code, not so much with stateless, since
> stateless code can't really listen to events in the first place.
>
I've done client, server, beans, mbeans -- a little of everything. I
understand that immutability is a great goal, but is utterly unrealistic
in some domains, e.g. client/bean/mbean code.
--
Jess Holle
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
