On Mon, Jul 16, 2012 at 1:08 PM, Stephen Allen <[email protected]> wrote: > +1 for this idea as well. > > On Mon, Jul 16, 2012 at 11:37 AM, Andy Seaborne <[email protected]> wrote: >> On 16/07/12 19:11, Rob Vesse wrote: >>> >>> Yes +1 to that idea, I've had the same problem >>> >>> For backwards compatibility we could keep the overloads with the String >>> typed lang argument and just mark those methods as deprecated to gently >>> prod people to move to the newer overloads >>> >>> Rob >>> >>> >>> On 7/16/12 11:02 AM, "Ian Dickinson" <[email protected]> wrote: >>> >>>> Andy - >>>> This all sounds good to me. Would it be possible to use a different Java >>>> type than string for the lang? Just to avoid the confusion that I >>>> *still* suffer from in remembering which order the arguments go in >>>> Model.read( String, String, String ) >>>> >>>> Ian >>>> >>> > > Not only is it hard to remember the order of the arguments, it is hard > to remember exactly what all the options are for that string. In > addition the string makes client code brittle because it is easy to > make a typo and still have it compile. See Effective Java 2nd > Edition, Item 30 for a good discussion on this. > >> >> Yes and no. >> >> There is a "Lang" class - in RIOT currently it's an enum - it will be a >> plain class to make it open ended can't add an case to an enum without >> recompiling). c.f. ARQ's Symbol. >> > > I think Enum is what we should use here. The addition of new > languages is probably going to be a pretty infrequent event. In terms > of recompiling, we often make other changes that would require > recompiling between Jena versions, so this shouldn't be too much of a > burden. > > If we wanted to make this functionality extensible by end users (but I > don't see this being a common use case), that is also addressed by > having the enum extend an interface (Effective Java Item 34). > > >> If we add model.read(X, base, Lang) the null case is a compile problem and >> needs the null to be cast. Bother. > > Enums in Java are just fancy classes, so they are nullable. No compile > problem. >
Ooops, realized you were talking about the overload that would exist between the String and Lang versions. Yes this is annoying. An option may be to make a breaking change in Jena 3 and require Lang with no String overload. > >> And if it's Object and introspection, it does not help the original case of >> (X, String, String) much. Bother^2. >> >> So how much is model.read(X, base, null) used? Not much I guess but do >> changes mess up class/method signatures? >> >> WebReader.readSomething(...) only takes Lang, not a string for there hint. >> String hints exist and remain in Model.read only (and old FileManager) >> >> Andy
