On Thu, Oct 30, 2008 at 3:39 PM, Derek Gaston <[EMAIL PROTECTED]> wrote: > On Oct 30, 2008, at 10:14 AM, John Peterson wrote: > >> Yes, I think you are correct. Since the overwhelming sentiment seemed >> to be against a multiple inheritance hierarchy and more towards a >> 'pimpl' style design, I've worked up one more class diagram (attached) >> which takes into account Derek's ShellMatrix inheritance stuff as >> well. > > I still claim you're going to need a PetscShellMatrix object... but I'm > willing to be proven wrong. ;-)
Yeah... I think the issue is we don't want a ShellMatrix to have a single underlying implementation, i.e. be either a PetscShell OR an EpetraShell. When you "build()" a ShellMatrix, it must somehow retain the possibility to be used within either a PetscLinearSolver routine or an AztecLinearSolver routine, or whatever else you have (as I understand the design goals). I envision that the library's ShellMatrix will know how to initialize itself for different solvers, that is, it will be free to obtain and discard implementations at will, since for a Shell this is supposed to be a cheap operation. In any case, I don't claim that the current design will be unchanged during the implementation process ... it will definitely evolve as it gets coded up. -- John ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
