On Tue, Jan 05, 2016 at 01:17:09PM +0000, Florian Wilmshoever wrote: > Hi Dave, > unfortunately it's been awhile again since my last input to this. > Sorry about that and happy new year everybody :). > > Comments/answers on your suggestions below.
Am on vacation. Will look at it when I return. Thanks for this idea. Dave > > Another proposal/question from my side: > I had a more detailed look at the internal workings of generateDS and > couldn't really make up my mind on figuring out why things are > implemented the way they are. So please correct me if I'm wrong. > > My problem mostly evolves around the factory functions for the > schema-based objects making their decision whether to return the object > of type parent-class or type subclass. > Because this decision(implementation of the factory-functions) > is made based on the 'subclass'-classvariable of parent. > This results in the parent-class only being able to be usable by > one subclass, namely the one who last set its name to the 'subclass' > variable in parent's class. > > I would like to hear your opinion, if it's reasonable to change the > architecture > of generateDS so that you call constructor/factory on the subclass rather > than the parent class to return the proper type instead of using the factory > in > the parent class. > This could enable the system to use multiple subclasses with the same > parent and does not need the subclasses to link to their parent over the > 'subclass'-classvariable. > In the current setup such an approach would break the buildChildren()-method > though. > Or at least have it return objects of parent-class type instead of > subclass-type. > So to work around this one would have to make generateDS put an adjusted > version > of the buildChildren()-method into the subclasses as well which would work on > subclass-types > of that respective class instead of the types of the parent. > > I know this may be a long shot and will require quite an amount of change of > the inner > architecture, but nevertheless I would like to hear your opinion about it. > Also please tell me if > I took a complete wrong turn in my thinking and I'm the only one needing a > solution for this > anyways ;) > > Best Regards > Florian Wilmshöver > > > -----Ursprüngliche Nachricht----- > > Von: Dave Kuhlman [mailto:dkuhl...@davekuhlman.org] > > Gesendet: Freitag, 6. November 2015 00:37 > > An: Florian Wilmshoever > > Cc: generateds-users@lists.sourceforge.net > > Betreff: Re: [Generateds-users] subclass questions/issues > > > > On Wed, Nov 04, 2015 at 05:01:47PM +0000, Florian Wilmshoever wrote: > > > > > > Hi Dave, Hi list, > > > > > > first of all thanks for working in the adjustments for the attribute > > > references we talked about a while ago. > > > > > > generateDS has been working very well for me since then. > > > > > > > Florian, > > > > Good to hear from you. Glad to hear that generateDS.py is *mostly* > > working well for you. > > > > > Unfortunately like a couple of days ago I tried to integrate a second, > > > generated subclass into my program and came across some unexpected > > > behaviour. > > > > > > The setup is as follows. > > > -generated parent class 'parent' > > > -two generated subclasses 'subA' and 'subB' > > > > How did you generate the subclass modules? Did you use the "-s" > > command line option? > > > Yes, I did use the '-s'-option. > > > > > > > In my own module I'm parsing a xml file according to the base xsd of > > > parent. > > > > > > My module imports both subclass-modules to either create an instance > > > of 'subA' or 'subB' by using > > > > > > modulesubA.parse(filename) or modulesubB.parse(filename). > > > > > > The unexpected behaviour while testing this, no matter which parse > > > function I call, both will return an object of the last imported > > > subclass module. > > > > > > So if my imports look like this: > > > > > > 'import modulesubA' > > > 'import modulesubB' > > > > > > Both function calls: > > > 'modulesubA.parse(filename)' > > > 'modulesubB.parse(filename)' > > > will return an object of type 'subB'. > > > > A couple of things to think about (which you are likely already aware of): > > > > - When you import a module, it is only imported once, even if you > > try to import it twice. > > > > - Therefore, there will only be one instance of the superclass > > module. > > > > - And, therefore, that class variable 'subclass' will have a single > > value. > > > > > > > > > If you change the order of the imports, it will be the other way round. > > > > > > My initial observation is, that this is due to the assignment of the > > > classvariable 'subclass' in 'parent'. > > > > I believe you are right. > > > > > > > > It seems to get assigned from each modulesubA and modulesubB initially > > > while importing them and after that the factory function of the main > > > class will only return objects of the subclass which was assigned > > > there last. > > > > One thing to try is to make two copies of the superclass module, that is, > > copy > > the file itself. Or, if you are on Linux, make a symbolic link; I don't > > know how > > to do that on MS Windows. Then change the import statements in the > > subclass modules so they import two different modules. > > > I think this will be my fallback solution, though it's a bit contrary to my > understanding of how inheritance should work. > > > Or, here is an alternative that you can try -- Try to force the import to > > really > > happen a second time by doing something like the > > following: > > > > import sys > > sys.modules.pop('modulesuper') > > import modulesubA # or modulesubB > > > > Take a look at the documentation on 'sys.modules'. > > (https://docs.python.org/2/library/sys.html#sys.modules) > > It says: > > > > "This is a dictionary that maps module names to modules which have > > already been loaded. This can be manipulated to force reloading of > > modules and other tricks. Note that removing a module from this > > dictionary is not the same as calling reload() on the corresponding > > module object." > > > > So, possibly, if you do the sys.modules.pop(mod_name) before each import > > of a sub-module, that will change the behavior. > > > I'd rather not let my code change the import order or reload modules if don't > absolutely > have to. From an architecture point of view it seems to be more prone to > error or > maintenance issues than just having two base classes with the same content. > > > Actually, copying the superclass module (or making symbolic links) seems to > > me to be a better and less devious and less tricky approach. But, of > > course, I > > don't know your specific needs. > > > I agree. > > > Let me know if any of the above solves your problem. > > > > And, tell me if there is other help I can give. > Thanks. I really appreciate the your input and support on the matter. > > > > > Dave > > > > > > > > I may have an idea on how this could be solved, but I would like to > > > have some opinion or discussion from you first. > > > > > > I can also provide an minimal example of this but that will take me > > > some more time, so I hope it gets understood like I described. > > > > > > Let me know if you can reproduce this behavior or need me to provide > > > some more information. > > > > > > Thanks & Best Regards > > > Florian Wilmshöver > > > > > > > > > > -- > > > > Dave Kuhlman > > http://www.davekuhlman.org -- Dave Kuhlman http://www.davekuhlman.org ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
