Ed Leafe wrote: > On Jun 18, 2008, at 12:48 PM, Paul McNett wrote: > >>> No, the problem is that when saving a custom class, all properties >>> are recorded, so that we can tell what is changed in the subclass. I >>> need to find a way to handle these 'fake' properties better. >> Shouldn't you only save the properties that were "touched", and >> nothing >> else? I know I probably don't understand something, but finding out >> what >> is changed in the subclass should be as easy as looking at the >> properties assigned in the subclass, no? > > > No, because instances (and other classes) that use this class need to > have a base to compare *their* props against. Remember, a custom class > could then be used in another custom class, and this could then be > dropped into another class/form, etc. > > A simple first-gen form can use the Dabo base class as defaults. A > third-gen class that is contained in another 2nd-gen class has no such > basis to determine what its default should be. Think of the whole > __mro__ complexity for multiple inheritance, and then multiply that by > unlimited embedding of composite classes.
I guess I should bow out, but it seems much more complex than it needs to be. Why does it need to compare against anything? If you are modifying a third-generation, then you know which properties have been changed because there's a property assignment in that third-generation. Whatever the values of the other properties are, come from the second-generation, whether they are assigned there or in the first generation (and we don't care, because we are editing the third-generation). Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
