Makes sense to me. I'm always confused when names are a little similar but not identical. Can we just make a package called velocity2 or util2? Then keep the name the same ResourceLoader. It's a little more awkward sounding but is actually more understandable.
Will On Saturday, July 16, 2016, Claude Brisson <cla...@renegat.net> wrote: > I recently commited a long awaited internal API change, letting resource > loaders rely on Readers+encoding rather than on InputStreams > (commits 1752784 and 1752787). > > As Nathan commented in VELOCITY-793, "Providing B.C. support would be > nice, but is certainly not required nor even expected.". But I've got a > little issue of conscience about how to handle backward compatibility here. > > We've got a method to deprecate or suppress: > > InputStream getResourceStream(String source) > > and a new method: > > Reader getResourceReader(String source, String encoding) > > For now, I handled B.C. by deprecating getResourceStream(), and > implementing getResourceReader() to rely on the former one. It will serve > the purpose of letting existing resource loaders work without any > modification. > > But it has a big defect: someone implementing a new resource loader will > typically want to just implement all absctract methods, which means he will > have to implement getResourceStream(), and won't be asked to implement > getResourceReader()... > > So I think we have to deprecate the ResourceLoader class itself, and > create a new ResourceReader class. > > The new ResourceReader class will lack the getResourceStream() method. The > deprecated ResourceLoader class will inherit ResourceReader, leave > getResourceStream() abstract, and implement getResourceReader(). > > If you have another proposal to name the ResourceReader class, I'm > interested. (ResourceFetcher? ResourceProvider?) > > > Claude >
