Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 341207 - 'private' vs. Design for extensibility
Summary: 'private' vs. Design for extensibility
Status: RESOLVED FIXED
Alias: None
Product: EMFT
Classification: Modeling
Component: MWE (show other bugs)
Version: 1.1   Edit
Hardware: All All
: P3 minor (vote)
Target Milestone: M7   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-29 06:38 EDT by Boris holzer CLA
Modified: 2011-03-29 08:01 EDT (History)
1 user (show)

See Also:
sven.efftinge: indigo+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Boris holzer CLA 2011-03-29 06:38:34 EDT 
Build Identifier: M20110210-1200

I don't want to argue - feel free to close this issue if you don't agree - but I don't want be annoyed either:

I think it's a good idea for frameworks which are designed for extensiblity that framework's classes make their features visible in subclasses - i.e. one should prefer the keyword 'protected' and use 'private' carefully.
The actual trigger for this issue was org.eclipse.emf.mwe2.runtime.workflow.AbstractCompositeWorkflowComponent 
which has private children and just a setter.

I suggest to scan the FW for classes which are intended to be subclassed and make heavy use of the 'private' keyword. 



Reproducible: Always
Comment 1 Sven Efftinge CLA 2011-03-29 08:01:31 EDT 
I have added a protected getter method for the specific case. We generally use protected for methods but for fields we stick to private. Fields in API don't allow any indirection or delegation anymore in future changes. Please reopen for any additional concrete cases.