> -----Ursprüngliche Nachricht-----
> Von: Dave Kuhlman [mailto:dkuhl...@davekuhlman.org]
> Gesendet: Samstag, 16. Januar 2016 00:39
> An: Florian Wilmshoever
> Cc: generateds-users@lists.sourceforge.net
> Betreff: Re: [Generateds-users] subclass questions/issues
>
> > 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.
>
> Florian,
>
> I'm still trying to come up with a solution to your problem. I believe I've
> got a
> way to do what you need, if I understand that need correctly.
>
> Here is what makes it a bit difficult -- We must be able to use the submodules
> as a replacement for the supermodule. This means that the build methods
> (in the supermodule) must be able to create instances of the specific
> submodule that we are using at that time.
> Effectively, the superclass module must be wired to create subclasses from a
> specific subclass module at any given time.
Well the basic idea was to actually let subclasss inherit/have its own version
of the
build method to encapsulate the creation for the required objects. That way the
supermodule would not need to know about how many subclasses actually inherit
from the supermodule.
However as I said this is just my current state of thinking and I don't think
I've
understood your design well enough right now or now about all requirements to
it.
So to conclude: whatever solution we can come with is fine for me.
>
> However, in your case, I believe, you want to be able to change
> *which* subclass module is used while your application is running.
> Do I have that right? If so, ...
>
That reflects my use case pretty well, yes. :)
> I've attached a Python script that can be used to "fix up" the subclass
> references in a superclass module. It uses the module's __all__ attribute,
> which contains a list of generated classes, to update each class.
>
> Let's assume that you have two separate versions of the same
> submodule: submodule_1 and submodule_2. You have added different
> code to each of these submodules. Now, you want to be able to parse an
> XML instance document and create instances of the classes in submodule_1;
> later, while the same application is still running, you want to be able to
> parse
> an XML doc and create instances of the classes in submodule_2. Here is how
> you might do that with the help of this fix-up function:
>
> import fix_subclass_refs
> import supermodule
> import submodule_1
> import submodule_2
>
> fix_subclass_refs.fix_up_refs(supermodule, submodule_1)
> submodule_1.parse('data.xml')
>
> fix_subclass_refs.fix_up_refs(supermodule, submodule_2)
> submodule_2.parse('data.xml')
>
> Does this solve your problem?
>
Thanks a lot so far. I will test this out as soon as I can and let you know
about the result.
Best Regards
Florian
> If we can get something like this to work for you, then we can talk about
> including it with the distribution for others to use, also.
>
> Dave
>
>
> >
> > 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
