Re: ClassPath API comments, questions

Vitezslav Stejskal wrote:

>[resending Svata's response, it was hang somewhere]
>
>
>
>> I've started with API. I understand that the PathContent is specialized 
>> version of ClassPath which allows manipulation of its contents (add, 
>  
>
>
>Originally I thought that it would be useful to have a restricted 
>interface for query clients, who need ClassPath to access/find resources 
>and that PathContent/PathResource should be mainly used by clients 
>interesting in configuration and project management.
>  
>
Hmm, both PathContent & PathResource don't use anything from projects 
API (nor the Java Project API), so why they shouldn't be used by anybody 
intersted in Classpath management only? Or do you mean that we should 
separate the classpath 'consumers' from classpath 'providers'? In such 
case the PathContent and PathResource should be moved to SPI.

>I still think such division could be useful, please suggest how to to 
>that.
>  
>
Don't you think that classpath manipulation capability is interesting 
even for clients who do not bother with projects at all?

>  
>
>>> ClassPath.Entry, these classes seem to be independent, but PathResource 
>>> contains the same methods (not all, but many) as CP.Entry and in fact 
>>> serves the same purpose IMO. It seems that there is no support for 
>>  
>>
>
>Correct. 
>  
>
Ehm, sorry then, but why PathResource doesn't extend the CP.Entry?

>  
>
>>> creating the PathResource for FileObject (e.g. folder or jar), so in 
>>> fact it's not easy to add something to the PathContent.
>>> 
>>  
>>
>
>The PathResource does serve one additional purpose: it establishes an 
>identity for the folder (other than the folder identity) so that other IDE
>
OK. It's the R-9 I guess. Properly translated URL should be enough for 
the identification purposes.

[snip]

>>> 
>>> The SPI seems even more cryptic to me. Why is there EditableContent 
>>> interface when nothing implements it? Is it just a garbage? Why is there 
>>  
>>
>
>Garbage. Old relict from the times when I did not know whether dialogs 
>will have Ok/Cancel or Close. Please delete it.
>  
>
OK.

>  
>
>>> public ReadOnlyProxy class extending LightWeightProxy which is package 
>>> private? The ProxyPathContent.Control is for what (it does the same as 
>>> public method ProxyPathContent.setBases)? Again, no way how to create 
>>  
>>
>
>I tried to avoid ugly uses of ProxyFileSet, when in order to control 
>contents of the FileSet, you have to create a subclass. I tried to follow 
>a patten used in o.o.u.Mutex -- the one who creates has special access 
>rights through a "control" interface.
>  
>
I do understand this pattern, but look at the code:

public class ProxyPathContent extends PathContentBase {
   
    public static final class Control {
       
        public void setDelegates(PathContent[] bases, PathContent 
writable) {
            ...
        }
       
        public PathContent getControlledPath() {
            ...
        }
    }

    public ProxyPathContent(String id, Control c) {
        ...
    }

    ...

    public final void setBases(PathContent[] bases, PathContent del) {
        ...
    }
}


Is there any diference between PPC.setBases and PPC.Control.setDelegates 
methods which I've overlooked? If no, the PPC.Control is useless.

>  
>
>>> 
>>> The javadoc of ClassPath API is poor on some places (read completely 
>>> missing for some classes) and even if the overview docs are good 
>>> (explanations, pictures, references) the overall impression is bad. 
>>> Sorry. I am volunteering to improve the javadoc in exchange for 
>>> explanation how the API works and was intended to be used ;-).
>>  
>>
>
>_I_ am sorry - I can contribute to, but not in the next few hours. Say to 
>the end of this calendar week. Please do the work assignment.
>  
>
OK, I'll do, but I am not sure what the work is needed.

>  
>
>>> Here are some changes I am proposing to clean up the API/SPI (the list 
>>> isn't final):
>>> 
>>> * separate the project-independent part of classpath API to its own 
>>> module java/classpath (or perhaps separate project-dependent API to its 
>>> own module if the above would cause compatibility problems; 
>>  
>>
>
>OK, please rather create a pure java (w/o projects) API, we may end with 
>more stuff in there.
>  
>
Perhaps makes sense to keep the Classpath API in java/api module and 
move other stuff somewhere else. Please read my proposal for java module 
separations posted on this alias.

>  
>
>>> * deprecate Classpath.BASE{COMPILE, DEBUG, EXECUTE} fields, they can be 
>>> used only in deprecated ClassPath.getClassPath method
>>  
>>
>
>I thought I have already deprecated them. Mea culpa. Please do so.
>  
>
No problem.

>  
>
>>> * classes from classpath API shouldn't implement Node.Cookie (they are 
>>> accessed through lookup anyway provided by PEPs, etc.; in worst case use 
>>> superclass patching)
>>  
>>
>
>Relict from the time when node Lookups and LookupNodes did not function so 
>well. Should not be there.
>  
>
OK

>  
>
>>> * rename PathFactory to PathProvider and make it an interface
>>> * change PathFactory.findPath(Object) to 
>>> PathProvider.getClassPath(String pathId)
>>  
>>
>
>I would rather keep "find" in the name -- the path type may not be 
>supported at the object.
>  
>
I have no strong opinoin on "find" vs. "get", I just wanted to be 
consistent with Open API (e.g. Looku.Provider.getLookup(), 
Environment.Provider.getEnvironment(), 
ExplorerManager.Provider.getExplorerManager(), ...).

>  
>
>>> * change return type of PathProvider.getClassPath from PathContent to 
>>> ClassPath
>>> * create ClassPath.EMPTY constant; I've seen several times 
>>> PathContent.createPath(Collection.EMPTY, null, "blabla")
>>  
>>
>
>Yes, please.
>  
>
OK

>  
>
>>> * remove ProxyPathContent.Control; it's useless when public 
>>> ProxyPathContent.setBases exists
>>> 
>>  
>>
>See above for explanation of use cases.
>  
>
I still think it's useless and should be removed, see above explanation ;-).

-vita