(Somewhat arbitrarily choosing this message to reply to, as I think it covers all the points I want to respond to).
Ed Leafe wrote: > On Dec 10, 2006, at 10:38 PM, Paul McNett wrote: > >>> In the i-layer design Carl is >>> talking about, we'd create an empty subclass called 'iColumn', and >>> our dGrid would then have to be composed of iColumns. We'd then >>> subclass that to an empty iGrid class. >> So iGrid would have a ColumnClass of iColumn. Doesn't seem too >> complicated... > > At the very base, no it isn't terribly complicated, but when you get > to composite classes, it does get hairy. For a basic pageframe we'd > need dScrollPanel -> iScrollPanel -> dPage -> iPage; then for each of > the paged controls we'd need a d-version that uses iPage, followed by > an i-version. Classes like dDateTextbox would have to inherit from > iTextBox, not dTextBox, as well as every one of our dialog > subclasses. I can just imagine the headaches involved in re-writing > the datanav/AppWizard stuff to properly use these intermediate levels! It sounds icky, for little or no gain. At the most, I could see including a program to automatically generate the i-layer for people that want it. I can't see including the i-layer in Dabo. I mean, why have subclassing if you aren't going to use it? I have a small set of Dabo apps now, that instantiate controls not based directly off of Dabo, but off of my own intermediary layer that subclasses the Dabo classes. This wasn't hard to do but I made it as simple as possible to satisfy the need, which didn't include making my dPage inherit from my dScrollPanel subclass. But, if that becomes necessary in the future, it won't be difficult to change it. >> This assumes that they'd want to modify *Dabo*, and not their own >> subclasses. > > No, not really, although that's part of it. It's more like "If I > wrote this framework, I'd prefer if class X behaved this way". So you > modify the i-layer, and from that point on, all your apps have your > preferred behavior. It can either be replacing an existing Dabo > behavior, or adding something that is domain-specific. Again, this sounds like a job for subclassing and/or mixins like you suggested. I really don't get it: If you are going to modify Dabo and not submit a patch for the improvement, then you shouldn't modify Dabo but modify your subclass. Why would people expect the framework to provide this layer when they can just do it themselves? >> I don't think Carl was talking about us making this change in Dabo, >> but >> perhaps a downstream framework. > > No, this really has to be done at the framework level. If I'm being thick, I apologize. Why would it need to be part of the Dabo framework, and not the CarlDabo framework? >>> Now he can use his CarlTextBox everywhere, and it will behave >>> exactly like a dTextBox, except when it comes to the foo() method. >>> >> Exactly. >> >> I thought VFP frameworks did this so that people didn't need to worry >> about framework updates messing up their modifications, if they >> modified >> a few lines in the gazillion line textbox.valid, for example. > > That's precisely why this design was used. But take the case of modifying a line in a 500-line method (not that we have such unwieldy methods in Dabo). Either you modified it because it was a bug, in which case you should submit the patch so everyone benefits, or you just liked something about it better, in which case a patch should still be submitted to abstract out whatever little behavior you wanted to change into another method, subclass, and override that method. If Carl wanted something different there, someone else might too so why not provide a hook. But if I understand the i-layer concept correctly, that 500-line method would in effect get copied and pasted into the i-layer so that Carl could make his tweak in that one line. So now you have copied-and-pasted method code that is indeed shielded from changes in upstream Dabo, but it is copied-and-pasted for no good reason that I can see, and is totally improper use of OOP. >> Like you, >> I just don't see this class of problem in Dabo, but perhaps if someone >> made a specialized sub-framework it would be seen as beneficial, which >> is why I answered what Carl asked for which was how to find all the >> dabo >> ui classes. > > VFP doesn't support multiple inheritance, and thus the mixin > solution is not available. You can sort of fake it with one of the > façade pattern implementations, but it's weak. VFP also doesn't have first-class function objects, or a solid foundation in OOP like Python has. It is stuck with a bunch of legacy gotchas and the strongly-imposed feeling (due partly to the inability to nest functions) that creating more classes and/or methods is a bad thing: put all the functionality in this one gargantuan method instead. I, like you, just don't think these same issues are present in Python. There are different issues, yes, but let's solve the issues as they present themselves, not by thinking that because this or that was great in VFP, it must be needed here too. > Having written the Class Designer, I feel certain that an i-layer is > completely unnecessary. Every one of the controls used on the design > surface is a native Dabo control, but with a couple of mixin classes > added to give them the behaviors needed in the Designer instead of > the normal runtime behaviors. In all my years of working with > Codebook and the i-layer, I've never seen an i-layer customization > that even came close to that level of modification. Exactly. You used the solution that presented itself from Python, and it was simple and elegant. -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
