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. 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 ------------------------------------------------------------------------------ _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
