|
Re: [DataBinding] Interface anomalies for types [message #447513 is a reply to message #447502] |
Fri, 07 April 2006 16:54 |
Dave Orme Messages: 424 Registered: July 2009 |
Senior Member |
|
|
Daniel Krügler wrote:
> I wonder, why IObservableValue.getValueType(), IConverter.getFromType(),
> and IConverter.getToType() return Object instead of Class?
>
> This seems both unnecessarily unsafe and inconsistent to other parts of
> the library returning types, e.g. Property.getPropertyType(), which uses
> the more natural return type Class.
>
> The same questions apply to the signatures of other methods, e.g.
>
> ComputedValue.ComputedValue(Object valueType) // Note: Object instead
> //of Class!
Property is used for describing JavaBeans-style properties on Java
objects, so it uses java.lang.Class to specify types.
However, in general, data binding needs to be able to work with type
systems that require metaclass objects of other than java.lang.Class.
For example, EMF uses EClass to replace java.lang.Class. db4objects
uses String names to represent types generically across Java and .NET.
This lets us be compatible with those frameworks or anything else
someone might invent.
Regards,
Dave Orme
|
|
|
Re: [DataBinding] Interface anomalies for types [message #447535 is a reply to message #447513] |
Mon, 10 April 2006 06:49 |
Daniel Krügler Messages: 853 Registered: July 2009 |
Senior Member |
|
|
David J. Orme wrote:
> Daniel Krügler wrote:
>
>> I wonder, why IObservableValue.getValueType(), IConverter.getFromType(),
>> and IConverter.getToType() return Object instead of Class?
[snip]
>> The same questions apply to the signatures of other methods, e.g.
>>
>> ComputedValue.ComputedValue(Object valueType) // Note: Object instead
>> //of Class!
> Property is used for describing JavaBeans-style properties on Java
> objects, so it uses java.lang.Class to specify types.
>
> However, in general, data binding needs to be able to work with type
> systems that require metaclass objects of other than java.lang.Class.
>
> For example, EMF uses EClass to replace java.lang.Class. db4objects
> uses String names to represent types generically across Java and .NET.
> This lets us be compatible with those frameworks or anything else
> someone might invent.
Thanks for clarification, David. But I strongly recommend to emphasize
both this capability of the binding framework to support "generalized"
types and to document the fact more clearly, that getXXType does not
necessarily return objects different from Class. The current docs, which
say something like
"The value type of this observable value, or <code>null</code> if this
observable value is untyped."
do not clearly say that. Something like a note, which says that the
returned Object must not necessarily be of Class type, would be very
good.
But this discussion leads to another important point: Which requirements
(if any) does the binding framework have for those generalized types? Is
identity based on object identity or on equality? Do there exists
requirements on ordering?
Thanks and Greetings from Bremen,
Daniel Krügler
|
|
|
|
Powered by
FUDForum. Page generated in 0.03543 seconds