Vincent Massol wrote: > On Aug 24, 2008, at 10:56 PM, Sergiu Dumitriu wrote: > >> Vincent Massol wrote: >>> 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. > > 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. >
I understand now. Yes, the implementations should not be for the public, meaning that the developers of the official platform can use (inherit) them internally, and we can change whatever we want between releases, but third party code should never rely on these implementations. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
