Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] FW: Changing an interface signature for 6.1 in the MemoryBrowser importer/exporter

You'd have to bump up the major version to avoid API tooling errors, no?

On Fri, Jan 22, 2010 at 11:57 AM, Pawel Piech <pawel.piech@xxxxxxxxxxxxx> wrote:
Hi Randy,
Since you want to make an API breaking change, my recommendation would be to bump up the major version of the memory plugin and component.  The overall CDT project is moving the major version so there's no conflict there.

Cheers,
Pawel


Rohrbach, Randy wrote:
Folks

   I sent this out yesterday, but did ot get any comments back. So I am
resending it again
   to make sure it did not get lost in the shuffle.

   There is a bugzilla defect 299945 (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=299945 )
   which complains about the lack of retention of the entered dialog
information. You keep    needing to reenter some informational fields when the dialog is
brought up.

   The submitter ( Teodor Madan ) provided a patch which resolved most
of the issues. I added
   to it and put another patch back on the defect.

   The issue is that Teodor changed a signature definition
public Control createControl(Composite parent, IMemoryBlock memBlock,
IDialogSettings properties, ExportMemoryDialog parentDialog);

   for the properties parameter this used to be a pure Properties
parameter. In the original
   code Ted just allocated a dummy and passed it in. Teodor changed it
to be an IDialogSettings
   entry so he could use the standard dialog settings persistence of a
plugin. This seems like
   a pretty good idea to me as opposed to inventing some new form of
persistence. But it does
   change the signature from an API perspective.

   I am under the impression that the only importers/exporters around
are the ones included in
   the standard CDT code. So instead of creating a "2" version of the
interface and changing to
   fit that style for backward compatibility ( which of course is
doable ), I am asking anyone
   if they object to this interface change.

   Please let me know.

   Thanks

Randy
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top