This is actually another issue with the inheriting style approach I had originally proposed - it requires each ancestor to maintain the set of declared styles so that descendants can inherit them. In many (if not most) cases, the only time an application will need these styles is when the UI is initially constructed - then they are no longer needed. However, using the inheriting approach, a caller would be required to manually remove them. Using the include approach, they will automatically go out of scope and be garbage collected unless the caller maintains a reference to them.
On Jul 5, 2010, at 8:02 AM, Greg Brown wrote: >>> Again, I'm not sure how often this might be used in a real application, >>> but it could be supported easily. >> Me too, but if it's "easy" to implement why not ? > > Because there are other issues, like the fact that listening for style > changes on these objects would require keeping them in memory, which may not > be the desired behavior. I'm not saying we won't support it - just haven't > thought through all of the various scenarios yet. >
