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 <[email protected]> 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 <[email protected]> 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
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to