The pont of difference is because people code like:
if( handle instanceof FooService){
FooService service = (FooService) handle;
service.hack("hack");
}
A wrapper breaks this approach :-P As in no naked FooService handles
escape into the wild from the catalog.
I would of liked code to do the following:
if( handle.canResolve(FooService.class)){
FooService service = resolve(FooService.class, new
NullProgressListener );
service.hack("hack");
}
A wrapper still breaks this approach (even if in "unwraps"), because the
resulting FooService is not complete.
To be honest the only real thing to do here is the separate subclass
method game; but even that just pushes the problem
of calling super one level away from the library.
class Service {
public final canResolve( Class adaptee ){
return adaptee != null && (shouldResolve( adaptee ) ||
RenderManager.canResolve( this, adaptee ));
}
protected abstract shouldResolve( Class adaptee ){ // at least
adaptee can no longer be null
return false; // please override in your subclass for fun
profit and caching
}
}
All Good here:
class MyService extends Service {
protected abstract shouldResolve( Class adaptee ){ // at least
adaptee can no longer be null
return adaptee == Fish.class;
}
}
Back to badland:
class YourService extends MyService {
protected abstract shouldResolve( Class adaptee ){
return adaptee == Mollusk.class || super.shouldResolve(
adaptee );
}
}
> It was a choice between using a wrapper so that existing implementations
> could remain untouched, or modify every existing resource handle to
> process the extension point.
>
> Both ways have their benefits. Its unfortunate we didn't take the same
> direction, this makes the gap between the geotools catalog and udig
> catalog even larger.
>
> -Justin
>
> Jody Garnett wrote:
>
>> Well I sent this to the wrong list; but some of the stuff on
>> IGeoResource is of interest; although it sounds like
>> Justin took a different track in terms of using wrappers.
>>
>>> Started page the programmers guide reference section ...
>>> -
>>> http://udig.refractions.net/confluence/display/DEV/Upgrade+from+1.0+to+1.1
>>>
>>>
>>> Assume this can be updated as backwards incompatibilities are pointed
>>> out. If you know
>>> of any I missed please update the page :-)
>>>
>>> Jody
>>>
>>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Geotools-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>> !DSPAM:1004,45661e3c146636309890654!
>>
>>
>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
