Twitter github

Internal Extension Points

What do people think about internal extension points? Currently, there is no concept about “internal” extension points in Eclipse besides using the convention of having “internal” (ie., internalTweaklets) in the extension point name along with some terse documentation. I know there are also products that don’t ship extension point schemas (.exsd) to prevent their users from extending schemas they don’t want. This is kind of funny because Eclipse is still aware of the extension point it just can’t help the user extend it… since there’s no schema… in essence… the extension point is being hidden… yet it is still there:

I think we can do better than this and try to mimick the concept we have with internal packages and x-friends. For example, imagine an extension point you wanted to define to be used just but your plug-ins for now… it’s useful for you internally but not ready to open to the public yet. In PDE, we could allow you to define an extension point as internal and maybe give it some “friends” that wouldn’t be flagged as discouraged access to the extension point.

What does the community think? Is this something valuable for people?

  • David Carver

    PDE using the EMF XSD library to read and write the schemas, and then using the data model provided for editing would be even better. This way it opens up extension points to other patterns.

  • David Carver

    PDE using the EMF XSD library to read and write the schemas, and then using the data model provided for editing would be even better. This way it opens up extension points to other patterns.

  • Chris Aniszczyk (zx)

    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.

  • Chris Aniszczyk (zx)

    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.

  • Kevin McGuire

    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.

  • Kevin McGuire

    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.

  • Laurent Goubet

    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.

  • Laurent Goubet

    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.

  • Sven Efftinge

    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.

  • Sven Efftinge

    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.

  • Chris Aniszczyk (zx)

    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”

  • Chris Aniszczyk (zx)

    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”