On Fri, 11 Mar 2011, Derek Gaston wrote:
>> What arguments do we want these to take? An EquationSystems& and >> string as usual? I'd think a System& would be more elegant, except >> that then when someone needed more than a bare-bones System (as >> everyone does...) they'd have to downcast it to ImplicitSystem or >> some such, whereas at least now we hide the ugly downcasts in >> EquationSystems::get_system(). > > No need to pass any arguments (or do any casting)... they are creating > these classes... and they can store whatever they want _in_ the class > itself (including full pointers to the System, etc). This, to me is > the real reason to do things this way... because then when you are > managing multiple systems and equation systems all of the data can be > kept in one place (in the class). Doing things this way is dangerous long term - the more interdependencies you can get away with avoiding, the more flexibility your middleware code has. But the library code flexibility which allows people to do things this way (or whatever way they want) rather than trying to specify The One Correct specific function call sequence is a good thing, much better than my awful suggestions. I like it. --- Roy ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
