> On 14 Jul 2016, at 17:55, Patrick Reinhart <patr...@reini.net> wrote: > > Hi Paul, > > On 2016-07-13 10:28, Paul Sandoz wrote: > >> I see some comments already by Stuart and Alan, and concur with Alan >> about working closely with jigsaw-dev. >> Focusing on the public methods is good and then it will come down to >> naming them appropriately. Given that sub-classes can override the >> existing public Enumeration returning methods we most likely need to >> specify the implementation behaviour of the Stream returning methods >> i.e. specify in an @implSpec that they call the Enumeration returning >> methods. Later on it may be possible to sub-types to implement more >> optimally (but the Enumeration “string” is quite long and intertwined >> with the internal code base) > > When I understand you correctly here we should concentrate on the public > methods naming firstly? I initially was not sure, what a proper naming > for the steams method was. It seem to me reasonable the way Stuart pointed > them out on his first comment to name them something like this: > > Stream<URL> resources(String name) > Stream<URL> systemResources(String name) >
Yes. > Has anyone a better naming suggestion? For me those names would fit so > far. If we look into the stream characteristics I would suggest that it > has a unknown size and is immutable in both cases. Maybe the entries are > also distinct, but there I'm not sure. > I would expect the URLs to be distinct, but that might not be consistent with URL.equals i.e. i don’t trust URL handlers :-) therefore i would be wary of including the DISTINCT characteristic. Paul. > >> The protected findResources method may be trickier, i suggest leaving >> that one alone for now. > > From the point of a consumer of the public API I have no problems with > this approach, as I created the enhancement issue on the public methods > anyway. > > Better to deal with that when we know how to do it better. > > Cheers Patrick
