25 Aug
2008
25 Aug
'08
9:02 a.m.
On Aug 24, 2008, at 10:56 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
Yes but this was not the problem. The problem is for example if a user
wants to create, say, a XHTML2 macro based on our XHTML macro. He'll
have to have it injected for example (or inherit from it). In both
cases this means exposing the internal package (in components.xml or
in the import). Thus if the class name is changed for example, it'll
break the user. Same for protected methods which will also break
backward compat if used and modified.
But I think this is ok. It just means our component implementations
cannot be reused since they are private. We'll just need to make this
very clear.
Thanks
-Vincent
Hi,
We need to decide if we want our component implementations (the class
implementing the interface of a component) to be user-public or not.
By user-public I mean allowing user of the code to use them (for
composition, for inheritance). The alternative is to make them
internal and forbid users to import them. This means moving them to
an
internal package (see http://www.eclipse.org/articles/
article.php?file=Article-API-Use/index.html) and telling
our users that they change anytime so they shouldn't use them. This
would also mean we wouldn't have to go through a deprecation stage to
make any change to our components.
My initial reaction to this was that they should be public but the
more I think about it the more I think making them internal might be
the best choice.
Private. The component's description (the interface) is enough. If we
need a more detailed "interface", then maybe we should either create a
new component, or redesign the code using that component.
Implementations should stay hidden.