On Wed, 1 Feb 2012, Dmitry Karpeev wrote:
> PETSc isn't shy about changing the API every release :-)
Oh, believe me, we know... are you mentioning this to persuade *for*
or *against* backwards-incompatible API changes? ;-)
> We tend to thing it's the right thing to do, if used sparingly.
Ever
> We tend to thing it's the right thing to do, if used sparingly.
I'm all for it, but I appreciate that the discussion has converged on the
decision.
Most importantly (based on my personal experience with PETSc!) it should be
clearly spelled out in the release notes for the new version, as that's
On Feb 1, 2012, at 1:05 PM, Dmitry Karpeev wrote:
> PETSc isn't shy about changing the API every release :-)
> We tend to thing it's the right thing to do, if used sparingly.
>
> Dmitry.
>
> On Wed, Feb 1, 2012 at 12:57 PM, Derek Gaston wrote:
> I think so. Libmesh doesn't have so many users
PETSc isn't shy about changing the API every release :-)
We tend to thing it's the right thing to do, if used sparingly.
Dmitry.
On Wed, Feb 1, 2012 at 12:57 PM, Derek Gaston wrote:
> I think so. Libmesh doesn't have so many users that we shouldn't be
> allowed to evolve the API if there are j
I think so. Libmesh doesn't have so many users that we shouldn't be
allowed to evolve the API if there are justifiable causes.
I mean, we don't want to break everyone's code all the time, but we
shouldn't be so beholden to the old API just for the cause of backward
compatibility.
Derek
Sent fro
On Tue, 31 Jan 2012, Derek Gaston wrote:
Also: Screw backward compatibility. libMesh has been moving away from function
pointer stuff for a while (like Ben's new NonlinearSystem stuff).
Let's move to an all object oriented interface
Does "Screw backward compatibility in favor of OOP" exten
On Tue, 31 Jan 2012, Derek Gaston wrote:
Personally... just force people to inherit from the base class and
override virtuals. It's not _that_ much work That's what we do
in MOOSE and it's been working well
Also: Screw backward compatibility. libMesh has been moving away
from funct
Personally... just force people to inherit from the base class and override
virtuals. It's not _that_ much work
That's what we do in MOOSE and it's been working well
Also: Screw backward compatibility. libMesh has been moving away from
function pointer stuff for a while (like Ben's new
I'm tired of having to cook up hard-coded fptr and gptr arguments to
pass to methods like System::project_vector() and
ExactSolution::attach_exact_value(); I'd prefer to be able to pass in
function objects instead.
But I also want to avoid breaking backwards compatibility, so we need
some species
