Not a bad idea. On Sat, Jul 16, 2016 at 12:31 PM, Sergiu Dumitriu <sergiu.dumit...@gmail.com > wrote:
> If more backwards-incompatible changes are going to happen, maybe it's > best to do what several apache-commons project have done: move > everything to org.apache.velocity2. > > On 07/16/2016 09:11 AM, Nathan Bubna wrote: > > I like ResourceReader or ResourceProvider, as i get confused when classes > > have the same name and different packages. :) But i suppose > > ResourceLoader2 in all its ugliness solves both Will's confusion and my > > own. Ha! > > > > But in all seriousness, you know i'm a big "them that do the work make > the > > call" type of guy. I trust your judgement. > > > > On Sat, Jul 16, 2016 at 2:27 AM, Claude Brisson <cla...@renegat.net> > wrote: > > > >> I went on with the "2" suffix, but on the ResourceLoader class, hence a > >> ResourceLoader2 class. > >> > >> Claude > >> > >> > >> On 16/07/2016 10:54, Will Glass-Husain wrote: > >> > >>> 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 > >>>> > >>>> > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > >
