On 7/24/07, Ken McIvor <[EMAIL PROTECTED]> wrote: > Since my original comment about traits I have been working hard to > put my money where my mouth is. Attached is an experimental > rendering system with an alternative transform architecture that does > not require attribute change notification. Please let me know what > you think, everybody.
Hi Ken -- sorry for the radio silence, I'm not intentionally ignoring you. Real life has made some demands on my time of late, and probably will until next week, but I was able to download, read through and test your code. It looks very clean and is an impressive piece of work. I'll agree with your assessment above that from a code reading perspective, this looks a bit more digestible that what I have done using traits. But I don't think that closes the book on the subject -- for example, I have realized I am introducing too much complexity and trait forwarding, and I think I know a way to work around this, so I will be hacking through my version one more time while at the same time taking a closer look at yours. I also would like to hear more about the "hard to optimize" part, because that is not intuitively clear to me. I confess to being a meta-class ignoramus, so I am intrigued to study how you handled the canvas primitive cache problem using meta classes. How for example, if one modifies a Rectangle object which embodies a path primitive, would the canvas get the notification to update it's internal path representation (egg the agg_path_storage)?. With traits, I use the trait event handling mechanism so that when any of the box properties (left, width, top, etc...) are modified, the PathPrimitiveAgg would get a callback. So when the user does rect.left = 0.1 the agg path knows to update itself. This is pretty cool. As for code readability, I'll also add that as a traits newbie, I am probably making things harder than necessary. But there are a lot of gotchas with traits usage, particularly in the area of instantiation, because you can easily get bitten by shared class level data structures, especially in the presence of sync_traits. vis-a-vis properties vs traits, I second Peter's comment that once you've written 8,000 setters and getters and manually constructed properties, you'll probably evolve toward something like traits, w/o all the features. This is a library that has been bug and performance vetted in production applications for years, so we should seriously consider it as a properties alternative. I strongly encourage you to download Fernando's mplconfig sandbox stuff and try the edit_traits demo in the presence of a wx enabled traits. He is somewhat blown away by the fact that he got a sophisticated, nested GUI dialog w/o writing *any* code. Since you are a committed wx user, you might find this particularly appealing. But at the end of the day, I think the *notification* aspect of traits is the killer feature. I think your approach of working on a display PDF renderer interface is also a good one, for several reasons. It uses an established specification instead of a home grown one, and it makes it easier for us to consider things like integrating with Kiva or Chaco. I am glad you interpreted my mpl1 sketch in the right vein, as a lab in which people can advocate ideas as working code. Much more productive than lots of emails, I think. Hopefully next week we can come to some consensus and start merging our two lines. PS: I'm not ignoring you either Peter, but I won't be able to get to all your questions and comments until a bit later; as you know the harder problems take longer to address ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
