[FM3] TemplateModel interfaces cleanup

[Daniel Dekany <dd...@freemail.hu>]

While, yet again, I try to not invest too much into
TemplateModel-s/ObjectWrapping due to the possibility to switching to
MOP-s, I though some fast cleanup of concepts can help migration to
MOP-s, and can help quite much anyone who wants to wrap their head
around how things work. I would also do this for "safety", in case we
won't do MOP-s at all due to time constraints.

Renaming some TempltaeModel-s:
- TemplateScalarModel to TemplateStringModel
- TemplateCollectionModel to TemplateIterableModel
- TemplateCollectionModelEx to TemplateCollectionModel

TemplateSequenceModel should extend TemplateCollectionModel (I mean
the one we have renamed to, FM2 TemplateCollectionModelEx).

(And if we won't switch to MOP-s, then there will me more to do,
especially allowing non-String keys for "hashes"... that will be a
hard one.)

-- 
Thanks,
 Daniel Dekany

Re: [FM3] TemplateModel interfaces cleanup

[Daniel Dekany <dd...@apache.org>]

I have committed this:
https://github.com/apache/incubator-freemarker/commit/cae86e18e06df0475313072e71dfa2795816060f
It came with some other related changes, quote obvious ones I believe.
If someone wans to form an opinion about those, it's easy to extract
the details from this change log diff:
https://github.com/apache/incubator-freemarker/commit/cae86e18e06df0475313072e71dfa2795816060f#diff-0bd677a6f6a35914dd7b968e1caa9e6d

This touches lot of files. I hope it won't produce to much conflicts
with the Spring-related branch.

Now, I think we should rename TemplateSequenceModel to
TemplateListModel, and then at last all the iterable/list-like
TemplateModel follows the Java API nomenclature. Unless someone
disagrees, of course. (We still have TemplateHashModel[Ex] left in
that regard, which should be TemplateMapModel or such, but that can
wait until it will allow non-String keys... and then none of the
TemplateModel-s has a cryptic name.)

Saturday, March 4, 2017, 1:22:59 AM, Woonsan Ko wrote:

> On Fri, Mar 3, 2017 at 1:49 AM, Daniel Dekany <dd...@freemail.hu> wrote:
>> While, yet again, I try to not invest too much into
>> TemplateModel-s/ObjectWrapping due to the possibility to switching to
>> MOP-s, I though some fast cleanup of concepts can help migration to
>> MOP-s, and can help quite much anyone who wants to wrap their head
>> around how things work. I would also do this for "safety", in case we
>> won't do MOP-s at all due to time constraints.
> +1
>
>>
>> Renaming some TempltaeModel-s:
>> - TemplateScalarModel to TemplateStringModel
>> - TemplateCollectionModel to TemplateIterableModel
>> - TemplateCollectionModelEx to TemplateCollectionModel
> +1
>
>>
>> TemplateSequenceModel should extend TemplateCollectionModel (I mean
>> the one we have renamed to, FM2 TemplateCollectionModelEx).
> Right. +1.
>
> Cheers,
>
> Woonsan
>
>>
>> (And if we won't switch to MOP-s, then there will me more to do,
>> especially allowing non-String keys for "hashes"... that will be a
>> hard one.)
>>
>> --
>> Thanks,
>>  Daniel Dekany
>>
>

-- 
Thanks,
 Daniel Dekany

Re: [FM3] TemplateModel interfaces cleanup

[Woonsan Ko <wo...@apache.org>]

On Fri, Mar 3, 2017 at 1:49 AM, Daniel Dekany <dd...@freemail.hu> wrote:
> While, yet again, I try to not invest too much into
> TemplateModel-s/ObjectWrapping due to the possibility to switching to
> MOP-s, I though some fast cleanup of concepts can help migration to
> MOP-s, and can help quite much anyone who wants to wrap their head
> around how things work. I would also do this for "safety", in case we
> won't do MOP-s at all due to time constraints.
+1

>
> Renaming some TempltaeModel-s:
> - TemplateScalarModel to TemplateStringModel
> - TemplateCollectionModel to TemplateIterableModel
> - TemplateCollectionModelEx to TemplateCollectionModel
+1

>
> TemplateSequenceModel should extend TemplateCollectionModel (I mean
> the one we have renamed to, FM2 TemplateCollectionModelEx).
Right. +1.

Cheers,

Woonsan

>
> (And if we won't switch to MOP-s, then there will me more to do,
> especially allowing non-String keys for "hashes"... that will be a
> hard one.)
>
> --
> Thanks,
>  Daniel Dekany
>