Quoting Rickard Öberg <[email protected]>:
What do you think about the configuration proposal then?
Why are you having duplicate names in the first place? What's the
core reason for that?
I'm not having duplicate names myself, currently. Someone else might
do, in future project, or when someone extends his/hers project. Or
maybe I will have them in future. Since the big thing in this whole
composite-oriented programming, regarding this issue, is that instead
of saying this.something() you say someRole.something(), it would be
awkward that suddenly, you can NOT say someRole.something() if you
have someRole2.something(). Especially since roles are not aware of
ALL other roles of the composite they belong to (which is another
strength of COP and Qi4j).
If this matter would be made configurable, either per ES or per
entity, I think both your scenarios and my scenarios would be possible
and effective. Why rule out possible usecase-scenarios simply based on
your current usage of framework, if all usecase-scenarios would be
possible with a simple change? I'm assuming that the change would be
simple. If supporting QName-qualified keys in state's serialization
proves out to be some really difficult task, of course there is not
much point in that. Also, in future, there might be some other ways of
serializing entity state, which would eliminate the size-issue of the
current JSONizing-approach.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
