Ok.. so bringing this to a close. I think arguing about handling extensibility for stores and resources is a bit of a mute point since there would be a lot of other stuff to do if we want to handle this properly. So essentially I argee that we "cross" this bridge when we come to it. And the accept method for StoreInfoImpl and ResourceInfoImpl will throw an exception.
That said and thinking ahead, it should be doable to just add a generic visit method for ResourceInfo and StoreInfo, as well as for the "well known" subtypes we know about. This gives the visitor the freedom to handle ResourceInfo generically, or only choose a specific sub type. -Justin Andrea Aime wrote: > Justin Deoliveira ha scritto: >> <snip> >>> >>> Works for me, but how do we deal with code that wants to throw a >>> safeguard exception in the last else? The usual "there is a programing >>> error, I don't know what this thing is" kind of exception. >> Good point, never thought of that. However, everything in Catalog is >> more or less a "closed set" with the exception of StoreInfo and >> ResourceInfo. And for those if we really wanted we could have the >> ResourceInfoImpl.accept() and StoreInfoImpl.accept() methods throw the >> "unknown type" exception. > > Any option that avoids a hunt down in the code for such an obvious > problem is welcomed. Code telling you what you did wrong makes > development and maintenance much easier (too bad contract > based programming did not get mainstream). > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
