Hi Fréd, thanks for your suggestion. (I responded inline.) > I have to admit I'm not very keen to see an already overly complex class to > become even more complex adding complex field managment. Me neither, I agree. I was thinking to add the field watcher as an optional constructor parameter / setter, in-line with Alex's philosophy of you get what you pay for. This way the class itself won't become more complex, and also developers have a choice of whether they want to ask the collection to fulfil this role or not. How does that sound?
> I generally solve the problem at application level, using a decorator pattern > to my VO mixed with a dynamic class to, at sort events, dynamicaly add or > remove simple fields and forward their value to their complex counterpart, it > works as well when you have hierarchical data and you want to display them in > a flat datagrid, if those VO need to be sent on the server or the rest of > the application, I use the decoratee VO. That's a solution too, but some developers might not know how to do it (by using the decorator pattern or through bindings), might not have time, and might make mistakes implementing it. Plus, in my mind this is core framework functionality, and it's not there simply because (I imagine) the Adobe developers never got round to it. It's no stretch to me to think that if we monitor changes to objects and then resort collections based on those changes, we can and should do the same for nested chains of objects.
