[dale.lutz@safe.com: Re: [geos-devel] ABI protection]

[strk at refractions.net]

----- Forwarded message from Dale Lutz <dale.lutz at safe.com> -----

Date: Sat, 25 Jun 2005 12:05:22 -0700
From: "Dale Lutz" <dale.lutz at safe.com>
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Subject: Re: [geos-devel] ABI protection
To: <geos-devel at geos.refractions.net>

Hello strk, others,

> > Adding non-virtual methods will not break compatibility. If the method is
> virtual, I don't think you can add it without breaking compatibility.
> >
> > One option would be to (for now) make the new method a function external
> to the Node class and grant it friend status with Node. This way, it can
> work on the interals of Node without changing Node's face to the world.
> Depending on what the method does, this may not be practical.
> 
> I think non-virtual option is ok for the 2.1 branch.


I can confirm from direct experience that it is FINE to add virtual methods
without breaking compability so long as:

1) They are added at the BOTTOM of the list of methods for classes which
never have any children derived from them.  

2) They are not overloading a method that already exists, that is, they must
have a unique name



It is also absolutely no problem to add non-virtual methods any which way you
want.


We've had to deal with this with our FME plugin API as well as FME Objects,
and so long as we've followed these rules, all has been well.

Hope this helps.


Dale

----------------------------------------------------------------------
Dale Lutz              Safe Software Inc.                 dal at safe.com
VP Development         Surrey, BC, CANADA        phone: (604) 501-9985
                       http://www.safe.com         fax: (604) 501-9965
----------------------------------------------------------------------

> 


----- End forwarded message -----