Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 348603

Summary:	Can CompositeSourceContainer.fContainers have protected access instead of private
Product:	[Eclipse Project] Platform	Reporter:	Dobrin Alexiev <dalexiev>
Component:	Debug	Assignee:	Platform-Debug-Inbox <platform-debug-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	pawel.1.piech
Version:	4.1
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Dobrin Alexiev

2011-06-07 11:50:51 EDT

Build Identifier: I20101208-1300

My Source container derives from CompositeSourceContainer and I need aaccess to this member. 
Addding a setter for this meember is OK with me too. 



Reproducible: Always

Steps to Reproduce:
NA

Comment 1 Pawel Piech

2011-06-07 12:49:40 EDT

The class has been designed to be create once and not change afterward, so I'd be reluctant to change that assumption since there is a lot of multi-threaded access done for source lookup.  Although obviously the containers member initialization is not synchronized properly.  Could you just write your own to sub-class with proper synchronization?

Comment 2 Dobrin Alexiev

2011-06-07 17:41:43 EDT

(In reply to comment #1)
> The class has been designed to be create once and not change afterward, so I'd
> be reluctant to change that assumption since there is a lot of multi-threaded
> access done for source lookup.  Although obviously the containers member
> initialization is not synchronized properly.  Could you just write your own to
> sub-class with proper synchronization?

Are you saying that I should treat my container deriving from CompositeSourceContainer as kind of immutable object, once createSourceContainers() is called? 
In that case I need to remove my container from its director/container, create a new one, move over all children, make sure dispose() is not call on them. 
Sound complicated for the simple set to null task I have. 

Can instead we just have removeAllChildContaniers() that will NOT call dispose() on the children? 
It will have the same synchronization as dispose().

Comment 3 Pawel Piech

2011-06-07 18:51:37 EDT

(In reply to comment #2)
> Are you saying that I should treat my container deriving from
> CompositeSourceContainer as kind of immutable object, once
> createSourceContainers() is called? 
In short, yes.  I didn't design it this way, but it does appear to be so.  

> In that case I need to remove my container from its director/container, create
> a new one, move over all children, make sure dispose() is not call on them. 
> Sound complicated for the simple set to null task I have. 
> 
> Can instead we just have removeAllChildContaniers() that will NOT call
> dispose() on the children? 
> It will have the same synchronization as dispose().

I'm reluctant to change this basic aspect of the class's design because it is a public API and I wouldn't want anyone to be able to start calling the remove method on the standard containers that we have (project, default, etc.).  

Maybe I'm being paranoid :-)  Do you have to subclass this class for your use case (it's < 100 loc)?

Comment 4 Dobrin Alexiev

2011-06-08 15:39:30 EDT

> Do you have to subclass this class for your use case (it's < 100 loc)?

OK. I give up. I'll copy the class locally... or use reflection for now. 
You can reject the bug.

Comment 5 Pawel Piech

2011-06-09 13:38:29 EDT

(In reply to comment #4)
> > Do you have to subclass this class for your use case (it's < 100 loc)?
> 
> OK. I give up. I'll copy the class locally... or use reflection for now. 
> You can reject the bug.

I don't mean to be difficult.  I'd be more open to creating a new (MutableCompositeSourceContainer) along side the existing one if we have a use case for it in open source.