The difference between Introspector and the language really is irrelevant to a degree.
If the Introspector and JavaBeans APIs provide suitable capabilities and type-safety, then we're set in my book. If not, then /add /them -- don't invent something else entirely. If we want type-safe usage thereof from the language or compiler (e.g. a "->" operator), then add that as needed. Personally I think the "->" operator is just kind of silly syntactic sugar that's not worth chasing much (and having "." do some magic in the area is pure insanity). I'd really /like/ to see annotations on methods that automatically clue in Introspector, though -- rather than having to mess with BeanInfo directly, which is /not/ fun in my book. [For instance, telling JavaBeans persistence that a property is transient should only require an @Transient or some such on the getter or setter, not silly BeanInfo mucking.] I suppose one of the benefits of Introspector being a factory method is that one can create one's own my.new.improved.Introspector that does understand such annotations, though. -- Jess Holle Brett Ryan wrote: > What I'm trying to get at is we don't have type safety in properties. > Introspector is simply a convenience to find our assumed properties > for us. It's not part of the language but part of the class libraries > that come with the language. > > I think we've gone off on a tangent ;) > > -Brett. > > On Wed, Nov 5, 2008 at 4:36 AM, Jess Holle <[EMAIL PROTECTED]> wrote: > >> Brett Ryan wrote: >> >> Yes, these two are vastly different, as I've expressed earlier you >> can't simply identify a property on a Class, take my attached example >> a few posts ago and you'll see what I mean. >> >> When you traverse Foo.class.getDeclaredMethods() that match a pattern >> of set|get.* and then pair the two up as a property. as also >> mentioned, what if getFoo returned a String, while syntactically >> correct, this is not type safe. >> >> get/set methods hide the implementation, but they don't enforce the >> fact. A property enforces this by exposing the get/set as one. >> >> >> Er, you might not like the JavaBeans APIs, etc, but they do all of this. >> >> I won't claim the JavaBeans area does not need improvement (as per my >> previous posts on this thread), but it is disingenuous to claim that we >> don't already have properties today that unify getters and setters >> appropriately. Just because the means of attaining them are not the same >> syntactic sugar you see in another language does not mean that (a) they're >> not there and (b) that they're not usable. >> >> >> But it's not baked into swing and other areas where a component model >> is needed, there maybe API's out there, but they aren't something I >> can discover. If I'm given a component from some component author who >> has quite simply developed some swing control, how do I place that >> control on a designer and be able to expose the properties of that >> component? Exposing events aren't as bad although not as easy as if we >> had true events. >> >> In the end we do something like the attached example I posted a few >> posts ago that iterates over the classes declared methods. Even still, >> I've just realised my example doesn't take the Boolean `is' into >> account. >> >> >> The JavaBeans Introspector and BeanInfo APIs do all of this. If you're not >> using them yet dealing with Java components then you're missing the boat. >> >> http://bean-properties.dev.java.net may be one solution, but whatever >> the solution is the actual components need to be unified to support >> property discovery. >> >> If you do have a way to unify getters/setters into a property without >> having to try and discover them I'd be interested to see. >> >> >> Again, just use the JavaBeans APIs -- that's what they're there for. >> >> -- >> 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 -~----------~----~----~----~------~----~------~--~---
