Niclas Hedhman wrote: > On Tue, Feb 10, 2009 at 3:25 PM, Rickard Öberg <[email protected]> wrote: >> Niclas Hedhman wrote: >>> yes, better than what I just suggested. >>> >>> But, why would it be <T extends ValueComposite>, since we don't have >>> that restriction elsewhere? Same algorithm could be applied. >> Yes, we could, but I think one will be dealing with ValueComposite types >> more explicitly than with Entity/Composite types. We could relax it >> though, without any problem. Can you give an example where you'd want to >> refer to the type with an extended interface rather than the value type? >> If even one example, then I'm all for it. > > Well, we have a general guideline to separate the structural assembly > (i.e. the composite) from the type used by clients. If this applies > "in general", why wouldn't it apply to Values?
It's just that for Values you would typically refer explicitly to the ValueType, rather than any of the interfaces it extends. But, you're right, there's no inherent need to introduce this restriction here as opposed to the other places. >>> Now, question is how we handle this along a timeline; >>> 0.6 --> I wanted that out soonish. >>> Better Value support --> in this release or 0.7?? >> I'll try to push this through ASAP, because I neeeeeds it for StreamFlow >> UI. > > Excellent. Nothing like something really bad rash... > >> Without it it seems reeeeally painful to do editing UI's. How do >> people do it without helpers like this???! Seems like a lot of manual >> work... > > Yes, it IS!! And one reason why people feel Web UIs are 'easier'. Seriously? So I haven't missed anything? So, basically everyone is like a Pavlovian dog, so accustomed to the nasty electrical shocks that they don't bother anymore, or accept it as "just the way things are"? Wow. That's just sad. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
