Comments on: Internal Extension Points http://aniszczyk.org/2008/03/28/internal-extension-points/ work. life. open source. diatribes. Thu, 02 Sep 2010 21:30:00 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Chris Aniszczyk (zx) http://aniszczyk.org/2008/03/28/internal-extension-points/comment-page-1/#comment-684 Chris Aniszczyk (zx) Fri, 28 Mar 2008 16:18:00 +0000 http://aniszczyk.org/2008/03/28/internal-extension-points/#comment-684 Sure, but an informal description isn't the same as having tooling to help you understand you're using something internal. Imagine Eclipse without discouraged access warnings for packages, but expecting you to read the "documentation" Sure, but an informal description isn’t the same as having tooling to help you understand you’re using something internal. Imagine Eclipse without discouraged access warnings for packages, but expecting you to read the “documentation”

]]> By: Chris Aniszczyk (zx) http://aniszczyk.org/2008/03/28/internal-extension-points/comment-page-1/#comment-2782 Chris Aniszczyk (zx) Fri, 28 Mar 2008 16:18:00 +0000 http://aniszczyk.org/2008/03/28/internal-extension-points/#comment-2782 Sure, but an informal description isn't the same as having tooling to help you understand you're using something internal. Imagine Eclipse without discouraged access warnings for packages, but expecting you to read the "documentation" Sure, but an informal description isn’t the same as having tooling to help you understand you’re using something internal. Imagine Eclipse without discouraged access warnings for packages, but expecting you to read the “documentation”

]]> By: Sven Efftinge http://aniszczyk.org/2008/03/28/internal-extension-points/comment-page-1/#comment-683 Sven Efftinge Fri, 28 Mar 2008 16:11:00 +0000 http://aniszczyk.org/2008/03/28/internal-extension-points/#comment-683 I don't think that everything becomes public API just because it is technically available. API also consists of informal description on how to use it. So for me it would be enough to state it in the documentation that an extension point shouldn't be used. I don’t think that everything becomes public API just because it is technically available. API also consists of informal description on how to use it. So for me it would be enough to state it in the documentation that an extension point shouldn’t be used.

]]> By: Sven Efftinge http://aniszczyk.org/2008/03/28/internal-extension-points/comment-page-1/#comment-2781 Sven Efftinge Fri, 28 Mar 2008 16:11:00 +0000 http://aniszczyk.org/2008/03/28/internal-extension-points/#comment-2781 I don't think that everything becomes public API just because it is technically available. API also consists of informal description on how to use it. So for me it would be enough to state it in the documentation that an extension point shouldn't be used. I don’t think that everything becomes public API just because it is technically available. API also consists of informal description on how to use it. So for me it would be enough to state it in the documentation that an extension point shouldn’t be used.

]]> By: Laurent Goubet http://aniszczyk.org/2008/03/28/internal-extension-points/comment-page-1/#comment-682 Laurent Goubet Fri, 28 Mar 2008 15:56:00 +0000 http://aniszczyk.org/2008/03/28/internal-extension-points/#comment-682 Well This would interest me for sure ;) (I'm the one who asked this on #eclipse just yesterday :D).<br/><br/>As kevin implied, extension points we define are for now directly becoming API and must be maintained even when they are WIP or simply not aimed at being made publicly available.<br/><br/>Definetly +1 on this matter. Well This would interest me for sure ;) (I’m the one who asked this on #eclipse just yesterday :D ).

As kevin implied, extension points we define are for now directly becoming API and must be maintained even when they are WIP or simply not aimed at being made publicly available.

Definetly +1 on this matter.

]]> By: Laurent Goubet http://aniszczyk.org/2008/03/28/internal-extension-points/comment-page-1/#comment-2780 Laurent Goubet Fri, 28 Mar 2008 15:56:00 +0000 http://aniszczyk.org/2008/03/28/internal-extension-points/#comment-2780 Well This would interest me for sure ;) (I'm the one who asked this on #eclipse just yesterday :D).As kevin implied, extension points we define are for now directly becoming API and must be maintained even when they are WIP or simply not aimed at being made publicly available.Definetly +1 on this matter. Well This would interest me for sure ;) (I’m the one who asked this on #eclipse just yesterday :D ).As kevin implied, extension points we define are for now directly becoming API and must be maintained even when they are WIP or simply not aimed at being made publicly available.Definetly +1 on this matter.

]]> By: Kevin McGuire http://aniszczyk.org/2008/03/28/internal-extension-points/comment-page-1/#comment-681 Kevin McGuire Fri, 28 Mar 2008 15:42:00 +0000 http://aniszczyk.org/2008/03/28/internal-extension-points/#comment-681 Makes sense, extension points are just the mechanism for cross plugin call dependency management. There's nothing inherent in them that implies that those are contracts for public consumption. They're orthogonal though obviously related concepts.<br/><br/>Not sure in practice how often it'd be needed but for those 1/100 cases it prevents accidental leaking or implying of API so valuable. Makes sense, extension points are just the mechanism for cross plugin call dependency management. There’s nothing inherent in them that implies that those are contracts for public consumption. They’re orthogonal though obviously related concepts.

Not sure in practice how often it’d be needed but for those 1/100 cases it prevents accidental leaking or implying of API so valuable.

]]> By: Kevin McGuire http://aniszczyk.org/2008/03/28/internal-extension-points/comment-page-1/#comment-2779 Kevin McGuire Fri, 28 Mar 2008 15:42:00 +0000 http://aniszczyk.org/2008/03/28/internal-extension-points/#comment-2779 Makes sense, extension points are just the mechanism for cross plugin call dependency management. There's nothing inherent in them that implies that those are contracts for public consumption. They're orthogonal though obviously related concepts.Not sure in practice how often it'd be needed but for those 1/100 cases it prevents accidental leaking or implying of API so valuable. Makes sense, extension points are just the mechanism for cross plugin call dependency management. There’s nothing inherent in them that implies that those are contracts for public consumption. They’re orthogonal though obviously related concepts.Not sure in practice how often it’d be needed but for those 1/100 cases it prevents accidental leaking or implying of API so valuable.

]]> By: Chris Aniszczyk (zx) http://aniszczyk.org/2008/03/28/internal-extension-points/comment-page-1/#comment-680 Chris Aniszczyk (zx) Fri, 28 Mar 2008 15:23:00 +0000 http://aniszczyk.org/2008/03/28/internal-extension-points/#comment-680 Unfortunately EMF isn't in the SDK so we can't do that.<br/><br/>Maybe in the Eclipse 4.0 timeframe we can revisit PDE and EMF integration. Unfortunately EMF isn’t in the SDK so we can’t do that.

Maybe in the Eclipse 4.0 timeframe we can revisit PDE and EMF integration.

]]> By: Chris Aniszczyk (zx) http://aniszczyk.org/2008/03/28/internal-extension-points/comment-page-1/#comment-2778 Chris Aniszczyk (zx) Fri, 28 Mar 2008 15:23:00 +0000 http://aniszczyk.org/2008/03/28/internal-extension-points/#comment-2778 Unfortunately EMF isn't in the SDK so we can't do that.Maybe in the Eclipse 4.0 timeframe we can revisit PDE and EMF integration. Unfortunately EMF isn’t in the SDK so we can’t do that.Maybe in the Eclipse 4.0 timeframe we can revisit PDE and EMF integration.

]]>