On Thu, 16 Oct 2008, John Peterson wrote:
>> I think I'll withhold judgment until I've seen the new ShellMatrix >> header file... It doesn't seem like they should necessarily be treated >> as members of the SparseMatrix inheritance family. It's bad enough >> that we can't simultaneously keep the LaspackMatrix interface >> up-to-date with changes to the Petsc one, and now we want to add one >> more family member? ;-) Eh; I'd rather have a nice OOP API that isn't completely implemented than a non-OOP API that isn't completeable. > Speaking of which, I forgot about the Trilinos stuff. it seems we've > made our lives harder than necessary by having nearly all the > functions in NumericVector and SparseMatrix be pure virtual. As long > as there is at least one pv function in the class to prevent > instantiations thereof, would it be easier on us if the rest had > default implementations of libmesh_error() and suitable a error > message? Like libmesh_not_implemented(), you mean? Yeah, that's probably the best way to go. Ideally, when you discover that your new pure virtual method is uncompilable until you add definitions for all the subclasses that might use it, that's just motivation to complete the work. In reality, none of us are that diligent, and if we're going to be lazy anyway we ought to make laziness more convenient. ;-) --- Roy ------------------------------------------------------------------------- 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
