Anything to do before 2.3.16?

[Daniel Dekany]

I will fix the bug with escaping "]]>". Anyone else wants to do
something before 2.3.16?

Yeah, if there will be an freemarker.template.AdvancedObjectWrapper,
it would be good if it appears in 2.3.16.

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Attila Szegedi-3]

I don't really want to do anything before 2.3.16.

Yeah, we can create such an "AdvancedObjectWrapper". Actually, I'd  
name it "UniversalObjectWrapper", declaring it wraps everything we  
know how to wrap in the default case (DOM, Jython, Rhino, and, well,  
everything else as POJOs). I started looking into this, and discovered  
to my horror that somewhere along the way, we apparently broke the  
BeansWrapper "outerIdentity" functionality. Not many people are  
complaining, so quite likely nobody really used it, but still (and in  
reality, that'd need to be part of the ObjectWrapper interface  
proper). Also, I did run into some issues with composing wrappers  
(namely, Rhino wrapper) and would like a bit of time to distill this  
in my head. So, I'd rather we don't wait with that for 2.3.16 -- it's  
long overdue and fixes some ugly bugs. (I'm suffering from log noise  
in certain production environment of ours because of <#attempt>/
<#recover> logs every recovered exception; some of our template  
developers decided exceptions are nice for control logic and we're  
sort-of stuck with it now...

Attila.

On 2009.09.11., at 10:28, Daniel Dekany wrote:

> I will fix the bug with escaping "]]>". Anyone else wants to do
> something before 2.3.16?
>
> Yeah, if there will be an freemarker.template.AdvancedObjectWrapper,
> it would be good if it appears in 2.3.16.
>
> --
> Best regards,
> Daniel Dekany

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

What about that (alleged?) issue where a Set is exposed as a sequence
(in additionally to as a collection), but then it turns out it can't
really do indexed access? (It's in one of the mails from Yuh-Ruey Che.
The one where ?contains stops due to this.)


Monday, September 14, 2009, 11:46:36 AM, Attila Szegedi wrote:

> I don't really want to do anything before 2.3.16.
>
> Yeah, we can create such an "AdvancedObjectWrapper". Actually, I'd  
> name it "UniversalObjectWrapper", declaring it wraps everything we  
> know how to wrap in the default case (DOM, Jython, Rhino, and, well,  
> everything else as POJOs). I started looking into this, and discovered
> to my horror that somewhere along the way, we apparently broke the  
> BeansWrapper "outerIdentity" functionality. Not many people are  
> complaining, so quite likely nobody really used it, but still (and in
> reality, that'd need to be part of the ObjectWrapper interface  
> proper). Also, I did run into some issues with composing wrappers  
> (namely, Rhino wrapper) and would like a bit of time to distill this  
> in my head. So, I'd rather we don't wait with that for 2.3.16 -- it's
> long overdue and fixes some ugly bugs. (I'm suffering from log noise  
> in certain production environment of ours because of <#attempt>/
> <#recover> logs every recovered exception; some of our template  
> developers decided exceptions are nice for control logic and we're  
> sort-of stuck with it now...
>
> Attila.
>
> On 2009.09.11., at 10:28, Daniel Dekany wrote:
>
>> I will fix the bug with escaping "]]>". Anyone else wants to do
>> something before 2.3.16?
>>
>> Yeah, if there will be an freemarker.template.AdvancedObjectWrapper,
>> it would be good if it appears in 2.3.16.
>>
>> --
>> Best regards,
>> Daniel Dekany
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Attila Szegedi-3]

My understanding was that it works now - DOW (DefaultObjectWrapper)  
will just copy the set into a list and use that, so all list  
operations work. Yuh-Ruey Che was arguing it should not do that and  
throw UnsupportedOperationException instead on indexed access. We  
clearly can't do that in order to not violate BWC.

Attila.

On 2009.09.14., at 11:55, Daniel Dekany wrote:

> What about that (alleged?) issue where a Set is exposed as a sequence
> (in additionally to as a collection), but then it turns out it can't
> really do indexed access? (It's in one of the mails from Yuh-Ruey Che.
> The one where ?contains stops due to this.)
>
>
> Monday, September 14, 2009, 11:46:36 AM, Attila Szegedi wrote:
>
>> I don't really want to do anything before 2.3.16.
>>
>> Yeah, we can create such an "AdvancedObjectWrapper". Actually, I'd
>> name it "UniversalObjectWrapper", declaring it wraps everything we
>> know how to wrap in the default case (DOM, Jython, Rhino, and, well,
>> everything else as POJOs). I started looking into this, and  
>> discovered
>> to my horror that somewhere along the way, we apparently broke the
>> BeansWrapper "outerIdentity" functionality. Not many people are
>> complaining, so quite likely nobody really used it, but still (and in
>> reality, that'd need to be part of the ObjectWrapper interface
>> proper). Also, I did run into some issues with composing wrappers
>> (namely, Rhino wrapper) and would like a bit of time to distill this
>> in my head. So, I'd rather we don't wait with that for 2.3.16 -- it's
>> long overdue and fixes some ugly bugs. (I'm suffering from log noise
>> in certain production environment of ours because of <#attempt>/
>> <#recover> logs every recovered exception; some of our template
>> developers decided exceptions are nice for control logic and we're
>> sort-of stuck with it now...
>>
>> Attila.
>>
>> On 2009.09.11., at 10:28, Daniel Dekany wrote:
>>
>>> I will fix the bug with escaping "]]>". Anyone else wants to do
>>> something before 2.3.16?
>>>
>>> Yeah, if there will be an freemarker.template.AdvancedObjectWrapper,
>>> it would be good if it appears in 2.3.16.
>>>
>>> --
>>> Best regards,
>>> Daniel Dekany
> --
> Best regards,
> Daniel Dekany

Attila.

--
twitter: http://twitter.com/szegedi
weblog: http://constc.blogspot.com






------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Monday, September 21, 2009, 10:08:03 AM, Attila Szegedi wrote:

> My understanding was that it works now - DOW (DefaultObjectWrapper)  
> will just copy the set into a list and use that, so all list  
> operations work. Yuh-Ruey Che was arguing it should not do that and  
> throw UnsupportedOperationException instead on indexed access. We  
> clearly can't do that in order to not violate BWC.

Um... My understanding was that the set was wrapped into
TemplateSequenceModel (among others), BUT get(int) still throws an
exception. Didn't tried it though... not yet. Here is again what he
said:

  > I did find another issue with BeansWrapper though: the seq_contains
  > builtin doesn't work correctly for Sets. The seq_contains builtin
  > first checks if the object is a TemplateSequenceModel and then uses
  > indexing operations (get(int)), before checking if the object is a
  > TemplateCollectionModel. Since Sets are wrapped in a
  > CollectionModel, which implements both TemplateSequenceModel and
  > TemplateCollectionModel, it's treated as a TemplateSequenceModel in
  > seq_containsBI, and get(int) throws an exception for Sets.

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Attila Szegedi-3]

On 2009.09.21., at 22:09, Daniel Dekany wrote:

> Monday, September 21, 2009, 10:08:03 AM, Attila Szegedi wrote:
>
>> My understanding was that it works now - DOW (DefaultObjectWrapper)
>> will just copy the set into a list and use that, so all list
>> operations work. Yuh-Ruey Che was arguing it should not do that and
>> throw UnsupportedOperationException instead on indexed access. We
>> clearly can't do that in order to not violate BWC.
>
> Um... My understanding was that the set was wrapped into
> TemplateSequenceModel (among others), BUT get(int) still throws an
> exception. Didn't tried it though... not yet. Here is again what he
> said:
>
>> I did find another issue with BeansWrapper though: the seq_contains
>> builtin doesn't work correctly for Sets. The seq_contains builtin
>> first checks if the object is a TemplateSequenceModel and then uses
>> indexing operations (get(int)), before checking if the object is a
>> TemplateCollectionModel. Since Sets are wrapped in a
>> CollectionModel, which implements both TemplateSequenceModel and
>> TemplateCollectionModel, it's treated as a TemplateSequenceModel in
>> seq_containsBI, and get(int) throws an exception for Sets.

Ah yes, that's indeed correct. Hm. Honestly, I'd change the order of  
interface checks in seq_contains. Reason being that  for iterating  
over the elements, TemplateCollectionModel is more effective, as the  
underlying list is not necessarily random access; think of a  
LinkedList. Do you see any backwards compatibility problems with that?  
I don't think there should be any.

Attila.


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Attila Szegedi-3]

On 2009.09.23., at 4:28, Attila Szegedi wrote:

> On 2009.09.21., at 22:09, Daniel Dekany wrote:
>
>> Monday, September 21, 2009, 10:08:03 AM, Attila Szegedi wrote:
>>
>>> My understanding was that it works now - DOW (DefaultObjectWrapper)
>>> will just copy the set into a list and use that, so all list
>>> operations work. Yuh-Ruey Che was arguing it should not do that and
>>> throw UnsupportedOperationException instead on indexed access. We
>>> clearly can't do that in order to not violate BWC.
>>
>> Um... My understanding was that the set was wrapped into
>> TemplateSequenceModel (among others), BUT get(int) still throws an
>> exception. Didn't tried it though... not yet. Here is again what he
>> said:
>>
>>> I did find another issue with BeansWrapper though: the seq_contains
>>> builtin doesn't work correctly for Sets. The seq_contains builtin
>>> first checks if the object is a TemplateSequenceModel and then uses
>>> indexing operations (get(int)), before checking if the object is a
>>> TemplateCollectionModel. Since Sets are wrapped in a
>>> CollectionModel, which implements both TemplateSequenceModel and
>>> TemplateCollectionModel, it's treated as a TemplateSequenceModel in
>>> seq_containsBI, and get(int) throws an exception for Sets.
>
> Ah yes, that's indeed correct. Hm. Honestly, I'd change the order of  
> interface checks in seq_contains. Reason being that  for iterating  
> over the elements, TemplateCollectionModel is more effective, as the  
> underlying list is not necessarily random access; think of a  
> LinkedList. Do you see any backwards compatibility problems with  
> that? I don't think there should be any.

Alternatively, I can split CollectionModel into ListModel and  
CollectionModel, latter only implementing TemplateCollectionModel;  
former extending latter.

Attila.


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Wednesday, September 23, 2009, 4:28:43 AM, Attila Szegedi wrote:

> On 2009.09.21., at 22:09, Daniel Dekany wrote:
>
>> Monday, September 21, 2009, 10:08:03 AM, Attila Szegedi wrote:
>>
>>> My understanding was that it works now - DOW (DefaultObjectWrapper)
>>> will just copy the set into a list and use that, so all list
>>> operations work. Yuh-Ruey Che was arguing it should not do that and
>>> throw UnsupportedOperationException instead on indexed access. We
>>> clearly can't do that in order to not violate BWC.
>>
>> Um... My understanding was that the set was wrapped into
>> TemplateSequenceModel (among others), BUT get(int) still throws an
>> exception. Didn't tried it though... not yet. Here is again what he
>> said:
>>
>>> I did find another issue with BeansWrapper though: the seq_contains
>>> builtin doesn't work correctly for Sets. The seq_contains builtin
>>> first checks if the object is a TemplateSequenceModel and then uses
>>> indexing operations (get(int)), before checking if the object is a
>>> TemplateCollectionModel. Since Sets are wrapped in a
>>> CollectionModel, which implements both TemplateSequenceModel and
>>> TemplateCollectionModel, it's treated as a TemplateSequenceModel in
>>> seq_containsBI, and get(int) throws an exception for Sets.
>
> Ah yes, that's indeed correct. Hm. Honestly, I'd change the order of  
> interface checks in seq_contains. Reason being that  for iterating  
> over the elements, TemplateCollectionModel is more effective, as the  
> underlying list is not necessarily random access; think of a  
> LinkedList. Do you see any backwards compatibility problems with that?

That was exactly what I asked earlier from you... but then there are
two of us who can't find out a such issue. Actually, I can, a little
one: If there is a TemplateModel that implements
TemplateCollectionModel incorrectly, but implements
TemplateSequenceModel correctly... I mean a custom one, because ours
are of course perfect. ;) So, then after the customer upgrades to
2.3.16, his application will be suddenly broken. But... that's his
mistake then! :->

Anyway, I still didn't get something here... Why do something
implement TemplateSequenceModel if it doesn't support get(int)? What
do I miss?

> I don't think there should be any.
>
> Attila.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Attila Szegedi-3]

On 2009.09.23., at 9:51, Daniel Dekany wrote:

> Anyway, I still didn't get something here... Why do something
> implement TemplateSequenceModel if it doesn't support get(int)? What
> do I miss?

Nothing. It doesn't really makes sense. We should really have a  
separate ListModel and CollectionModel in f.ext.beans.

Attila.


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Wednesday, September 23, 2009, 9:54:16 AM, Attila Szegedi wrote:

> On 2009.09.23., at 9:51, Daniel Dekany wrote:
>
>> Anyway, I still didn't get something here... Why do something
>> implement TemplateSequenceModel if it doesn't support get(int)? What
>> do I miss?
>
> Nothing. It doesn't really makes sense. We should really have a  
> separate ListModel and CollectionModel in f.ext.beans.

That's too late now, I think... /-: I thought maybe emulating the
get(int) could help, but then you had to keep the iterator alive, so
you can fetch all indexed items from the same iterator... doesn't
sound good.

Anyway, I go ahead and fix this ?seq_contains thing. And maybe some
other similar builtins (seq_index_of, etc.) has the same problem.

> Attila.

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Wednesday, September 23, 2009, 7:16:23 PM, Daniel Dekany wrote:

> Wednesday, September 23, 2009, 9:54:16 AM, Attila Szegedi wrote:
>
>> On 2009.09.23., at 9:51, Daniel Dekany wrote:
>>
>>> Anyway, I still didn't get something here... Why do something
>>> implement TemplateSequenceModel if it doesn't support get(int)? What
>>> do I miss?
>>
>> Nothing. It doesn't really makes sense. We should really have a  
>> separate ListModel and CollectionModel in f.ext.beans.
>
> That's too late now, I think... /-: I thought maybe emulating the
> get(int) could help, but then you had to keep the iterator alive, so
> you can fetch all indexed items from the same iterator... doesn't
> sound good.
>
> Anyway, I go ahead and fix this ?seq_contains thing. And maybe some
> other similar builtins (seq_index_of, etc.) has the same problem.

I need your help here. I have to detect if a sequence if a buggy one
or not (because in some situations BI-s should prefer sequences over
collections, unless of course the sequence is a buggy one). So I need
a method in freemarker.ext.beans to detect this. Like,
freemarker.ext.beans.CollectionModel could have a isFailingSequence()
method. Just an example... Yes, I know, I could try to get(int) and
see if it throws, or do other dirty hacks, but I don't think that's
desirable. Since CollectionModel has this bug, and we can't fix it
(not in 2.3 at least), it should at least help in writing workarounds.

Actually, even in 2.3.x, BeansWrapper could have an option that fixes
then issue, but is off by default.

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Attila Szegedi-3]

On 2009.09.23., at 19:16, Daniel Dekany wrote:

> Wednesday, September 23, 2009, 9:54:16 AM, Attila Szegedi wrote:
>
>> On 2009.09.23., at 9:51, Daniel Dekany wrote:
>>
>>> Anyway, I still didn't get something here... Why do something
>>> implement TemplateSequenceModel if it doesn't support get(int)? What
>>> do I miss?
>>
>> Nothing. It doesn't really makes sense. We should really have a
>> separate ListModel and CollectionModel in f.ext.beans.
>
> That's too late now, I think... /-:

Why? I don't think that changing BeansWrapper so that it wraps Lists  
in a new "ListModel extends CollectionModel implements  
TemplateSequenceModel" and all other Collections in a "CollectionModel  
extends StringModel implements TemplateCollectionModel" would cause  
any BWC problems. And it fixes the bug.

> I thought maybe emulating the
> get(int) could help, but then you had to keep the iterator alive, so
> you can fetch all indexed items from the same iterator... doesn't
> sound good.

No, that doesn't.

>
> Anyway, I go ahead and fix this ?seq_contains thing. And maybe some
> other similar builtins (seq_index_of, etc.) has the same problem.
>
>> Attila.
>
> --
> Best regards,
> Daniel Dekany

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Thursday, September 24, 2009, 9:27:35 AM, Attila Szegedi wrote:

> On 2009.09.23., at 19:16, Daniel Dekany wrote:
>
>> Wednesday, September 23, 2009, 9:54:16 AM, Attila Szegedi wrote:
>>
>>> On 2009.09.23., at 9:51, Daniel Dekany wrote:
>>>
>>>> Anyway, I still didn't get something here... Why do something
>>>> implement TemplateSequenceModel if it doesn't support get(int)? What
>>>> do I miss?
>>>
>>> Nothing. It doesn't really makes sense. We should really have a
>>> separate ListModel and CollectionModel in f.ext.beans.
>>
>> That's too late now, I think... /-:
>
> Why? I don't think that changing BeansWrapper so that it wraps Lists  
> in a new "ListModel extends CollectionModel implements  
> TemplateSequenceModel" and all other Collections in a "CollectionModel
> extends StringModel implements TemplateCollectionModel" would cause  
> any BWC problems. And it fixes the bug.

OK, I didn't dig into this, so maybe now it doesn't apply, but you
fiddle with public API there, which is seldom *strictly* BC. Only if
CollectionModel had no public constructor... but it has, so what if
someone has extended CollectionModel model? Maybe that's practically
impossible, in which case go ahead.

(BTW, I usually try to final everything that I didn't explicitly
designed to be extended, or prevent it to be extended with the
constructors. (Not that Java's Hello-World-optimized visibility rules
don't make this hard... but at least now they try to fix this with
superpackages.) I know it's a really annoying style for many, and they
will say, "Why the **** don't you just make it public and document
that there are no backward-compatibility there? ARGH!". But then, why
do they want that, if not for doing exactly that they aren't supposed
to do? So it's like "Why the **** don't you just let us risk shooting
ourselves on foot, if we chose to?" Well... I don't know... maybe I
think I'm your father. ;) Seriously, part of the goodness of your sw
is if how much people like it (after all, you write it to serve human
beings), but then, there is the danger of a kind of prostitution,
where you give up what you believe/know is right for popularity. Here,
if many want to extend a class, then maybe you will hear about it, and
you can add a correct extension mechanism (a config. option or like),
and that's more convenient and safer for the users than "hack" your
classes...)

>> I thought maybe emulating the
>> get(int) could help, but then you had to keep the iterator alive, so
>> you can fetch all indexed items from the same iterator... doesn't
>> sound good.
>
> No, that doesn't.
>
>>
>> Anyway, I go ahead and fix this ?seq_contains thing. And maybe some
>> other similar builtins (seq_index_of, etc.) has the same problem.
>>
>>> Attila.
>>
>> --
>> Best regards,
>> Daniel Dekany

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Thursday, September 24, 2009, 10:36:25 AM, Daniel Dekany wrote:

> Thursday, September 24, 2009, 9:27:35 AM, Attila Szegedi wrote:
>
>> On 2009.09.23., at 19:16, Daniel Dekany wrote:
>>
>>> Wednesday, September 23, 2009, 9:54:16 AM, Attila Szegedi wrote:
>>>
>>>> On 2009.09.23., at 9:51, Daniel Dekany wrote:
>>>>
>>>>> Anyway, I still didn't get something here... Why do something
>>>>> implement TemplateSequenceModel if it doesn't support get(int)? What
>>>>> do I miss?
>>>>
>>>> Nothing. It doesn't really makes sense. We should really have a
>>>> separate ListModel and CollectionModel in f.ext.beans.
>>>
>>> That's too late now, I think... /-:
>>
>> Why? I don't think that changing BeansWrapper so that it wraps Lists  
>> in a new "ListModel extends CollectionModel implements  
>> TemplateSequenceModel" and all other Collections in a "CollectionModel
>> extends StringModel implements TemplateCollectionModel" would cause  
>> any BWC problems. And it fixes the bug.
>
> OK, I didn't dig into this, so maybe now it doesn't apply, but you
> fiddle with public API there, which is seldom *strictly* BC. Only if
> CollectionModel had no public constructor... but it has, so what if
> someone has extended CollectionModel model?

[snip]

Indeed, since it has a public constructor, people my call that. (I
don't know why would they do that, but I assume you thought that's
useful, otherwise why would that be public AND published.) So if
CollectionModel become abstract... bang.

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Attila Szegedi-3]

Neither CollectionModel nor its subclasses would become abstract.  
Rather, they'd lose the TemplateSequenceModel interface. We could  
include a log warning in the CollectionModel constructor when it's  
invoked with a List saying "You should use ListModel instead".

Actually, I could leave CollectionModel in and deprecate it, and make  
sure BeansWrapper doesn't use it. I could create another class instead  
of it (except the name is too good...) that only has  
TemplateCollectionModel implemented (and have ListModel subclass it).

Attila.

On 2009.09.24., at 14:02, Daniel Dekany wrote:

> Thursday, September 24, 2009, 10:36:25 AM, Daniel Dekany wrote:
>
>> Thursday, September 24, 2009, 9:27:35 AM, Attila Szegedi wrote:
>>
>>> On 2009.09.23., at 19:16, Daniel Dekany wrote:
>>>
>>>> Wednesday, September 23, 2009, 9:54:16 AM, Attila Szegedi wrote:
>>>>
>>>>> On 2009.09.23., at 9:51, Daniel Dekany wrote:
>>>>>
>>>>>> Anyway, I still didn't get something here... Why do something
>>>>>> implement TemplateSequenceModel if it doesn't support get(int)?  
>>>>>> What
>>>>>> do I miss?
>>>>>
>>>>> Nothing. It doesn't really makes sense. We should really have a
>>>>> separate ListModel and CollectionModel in f.ext.beans.
>>>>
>>>> That's too late now, I think... /-:
>>>
>>> Why? I don't think that changing BeansWrapper so that it wraps Lists
>>> in a new "ListModel extends CollectionModel implements
>>> TemplateSequenceModel" and all other Collections in a  
>>> "CollectionModel
>>> extends StringModel implements TemplateCollectionModel" would cause
>>> any BWC problems. And it fixes the bug.
>>
>> OK, I didn't dig into this, so maybe now it doesn't apply, but you
>> fiddle with public API there, which is seldom *strictly* BC. Only if
>> CollectionModel had no public constructor... but it has, so what if
>> someone has extended CollectionModel model?
> [snip]
>
> Indeed, since it has a public constructor, people my call that. (I
> don't know why would they do that, but I assume you thought that's
> useful, otherwise why would that be public AND published.) So if
> CollectionModel become abstract... bang.
>
> --
> Best regards,
> Daniel Dekany

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Thursday, September 24, 2009, 2:07:04 PM, Attila Szegedi wrote:

> Neither CollectionModel nor its subclasses would become abstract.  
> Rather, they'd lose the TemplateSequenceModel interface.

Losing an interface is very much not BC.

> We could include a log warning in the CollectionModel constructor
> when it's invoked with a List saying "You should use ListModel
> instead".
>
> Actually, I could leave CollectionModel in and deprecate it, and make
> sure BeansWrapper doesn't use it. I could create another class instead
> of it (except the name is too good...) that only has  
> TemplateCollectionModel implemented (and have ListModel subclass it).

Then BeansWrapper will generate a lot of objects that is not
"instanceof CollectionModel", but earlier it was... Not like
BeansWrapper has formally promised it will pack List-s and like into
CollectionModel (I hope it didn't at least...), but still, it doesn't
sound BC in practice. After all, this will be a drop-in replacement
for 2.3.15.

--
Best regards,
 Daniel Dekany

> Attila.
>
> On 2009.09.24., at 14:02, Daniel Dekany wrote:
>
>> Thursday, September 24, 2009, 10:36:25 AM, Daniel Dekany wrote:
>>
>>> Thursday, September 24, 2009, 9:27:35 AM, Attila Szegedi wrote:
>>>
>>>> On 2009.09.23., at 19:16, Daniel Dekany wrote:
>>>>
>>>>> Wednesday, September 23, 2009, 9:54:16 AM, Attila Szegedi wrote:
>>>>>
>>>>>> On 2009.09.23., at 9:51, Daniel Dekany wrote:
>>>>>>
>>>>>>> Anyway, I still didn't get something here... Why do something
>>>>>>> implement TemplateSequenceModel if it doesn't support get(int)?  
>>>>>>> What
>>>>>>> do I miss?
>>>>>>
>>>>>> Nothing. It doesn't really makes sense. We should really have a
>>>>>> separate ListModel and CollectionModel in f.ext.beans.
>>>>>
>>>>> That's too late now, I think... /-:
>>>>
>>>> Why? I don't think that changing BeansWrapper so that it wraps Lists
>>>> in a new "ListModel extends CollectionModel implements
>>>> TemplateSequenceModel" and all other Collections in a  
>>>> "CollectionModel
>>>> extends StringModel implements TemplateCollectionModel" would cause
>>>> any BWC problems. And it fixes the bug.
>>>
>>> OK, I didn't dig into this, so maybe now it doesn't apply, but you
>>> fiddle with public API there, which is seldom *strictly* BC. Only if
>>> CollectionModel had no public constructor... but it has, so what if
>>> someone has extended CollectionModel model?
>> [snip]
>>
>> Indeed, since it has a public constructor, people my call that. (I
>> don't know why would they do that, but I assume you thought that's
>> useful, otherwise why would that be public AND published.) So if
>> CollectionModel become abstract... bang.
>>
>> --
>> Best regards,
>> Daniel Dekany
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Attila Szegedi-3]

How about explicitly testing for "instanceof CollectionModel" there?  
No other TemplateSequenceModels are buggy, AFAIK. If there were a  
BeansWrapper API, it would basically just do the same.

Attila.

On 2009.09.23., at 22:29, Daniel Dekany wrote:

> Wednesday, September 23, 2009, 7:16:23 PM, Daniel Dekany wrote:
>
>> Wednesday, September 23, 2009, 9:54:16 AM, Attila Szegedi wrote:
>>
>>> On 2009.09.23., at 9:51, Daniel Dekany wrote:
>>>
>>>> Anyway, I still didn't get something here... Why do something
>>>> implement TemplateSequenceModel if it doesn't support get(int)?  
>>>> What
>>>> do I miss?
>>>
>>> Nothing. It doesn't really makes sense. We should really have a
>>> separate ListModel and CollectionModel in f.ext.beans.
>>
>> That's too late now, I think... /-: I thought maybe emulating the
>> get(int) could help, but then you had to keep the iterator alive, so
>> you can fetch all indexed items from the same iterator... doesn't
>> sound good.
>>
>> Anyway, I go ahead and fix this ?seq_contains thing. And maybe some
>> other similar builtins (seq_index_of, etc.) has the same problem.
>
> I need your help here. I have to detect if a sequence if a buggy one
> or not (because in some situations BI-s should prefer sequences over
> collections, unless of course the sequence is a buggy one). So I need
> a method in freemarker.ext.beans to detect this. Like,
> freemarker.ext.beans.CollectionModel could have a isFailingSequence()
> method. Just an example... Yes, I know, I could try to get(int) and
> see if it throws, or do other dirty hacks, but I don't think that's
> desirable. Since CollectionModel has this bug, and we can't fix it
> (not in 2.3 at least), it should at least help in writing workarounds.
>
> Actually, even in 2.3.x, BeansWrapper could have an option that fixes
> then issue, but is off by default.
>
> --
> Best regards,
> Daniel Dekany

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Attila Szegedi-3]

On 2009.09.24., at 22:31, Daniel Dekany wrote:

> Thursday, September 24, 2009, 2:07:04 PM, Attila Szegedi wrote:
>
>> Neither CollectionModel nor its subclasses would become abstract.
>> Rather, they'd lose the TemplateSequenceModel interface.
>
> Losing an interface is very much not BC.

Actually, I believe the reason we implemented TemplateSequenceModel  
for all Java collections wrapped through BeansWrapper was that it has  
a size() method. If - say, for 2.4 - I did indeed split the  
implementation into a CollectionModel (only implements TCM) and  
ListModel (extends CollectionModel, implements TSM), then non-List  
collections, i.e. all Sets will no longer expose size, i.e. they won't  
work with the ?size built-in. Also, they previously could be used for  
sequence concatenation with + operator, and that too will no longer  
work.

Attila.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Friday, October 2, 2009, 3:59:09 PM, Attila Szegedi wrote:

> How about explicitly testing for "instanceof CollectionModel" there?  
> No other TemplateSequenceModels are buggy, AFAIK.

But CollectionModel-s are not buggy sequences when they don't wrap a
Set. So, if you do collectionModel?seq_last_index_of(item), I rather
don't iterate through all items of it, just use indexed access and
move backwards.

> If there were a
> BeansWrapper API, it would basically just do the same.
>
> Attila.
>
> On 2009.09.23., at 22:29, Daniel Dekany wrote:
>
>> Wednesday, September 23, 2009, 7:16:23 PM, Daniel Dekany wrote:
>>
>>> Wednesday, September 23, 2009, 9:54:16 AM, Attila Szegedi wrote:
>>>
>>>> On 2009.09.23., at 9:51, Daniel Dekany wrote:
>>>>
>>>>> Anyway, I still didn't get something here... Why do something
>>>>> implement TemplateSequenceModel if it doesn't support get(int)?  
>>>>> What
>>>>> do I miss?
>>>>
>>>> Nothing. It doesn't really makes sense. We should really have a
>>>> separate ListModel and CollectionModel in f.ext.beans.
>>>
>>> That's too late now, I think... /-: I thought maybe emulating the
>>> get(int) could help, but then you had to keep the iterator alive, so
>>> you can fetch all indexed items from the same iterator... doesn't
>>> sound good.
>>>
>>> Anyway, I go ahead and fix this ?seq_contains thing. And maybe some
>>> other similar builtins (seq_index_of, etc.) has the same problem.
>>
>> I need your help here. I have to detect if a sequence if a buggy one
>> or not (because in some situations BI-s should prefer sequences over
>> collections, unless of course the sequence is a buggy one). So I need
>> a method in freemarker.ext.beans to detect this. Like,
>> freemarker.ext.beans.CollectionModel could have a isFailingSequence()
>> method. Just an example... Yes, I know, I could try to get(int) and
>> see if it throws, or do other dirty hacks, but I don't think that's
>> desirable. Since CollectionModel has this bug, and we can't fix it
>> (not in 2.3 at least), it should at least help in writing workarounds.
>>
>> Actually, even in 2.3.x, BeansWrapper could have an option that fixes
>> then issue, but is off by default.
>>
>> --
>> Best regards,
>> Daniel Dekany

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Friday, October 2, 2009, 4:42:38 PM, Attila Szegedi wrote:

> On 2009.09.24., at 22:31, Daniel Dekany wrote:
>
>> Thursday, September 24, 2009, 2:07:04 PM, Attila Szegedi wrote:
>>
>>> Neither CollectionModel nor its subclasses would become abstract.
>>> Rather, they'd lose the TemplateSequenceModel interface.
>>
>> Losing an interface is very much not BC.
>
> Actually, I believe the reason we implemented TemplateSequenceModel  
> for all Java collections wrapped through BeansWrapper was that it has
> a size() method. If - say, for 2.4 - I did indeed split the  
> implementation into a CollectionModel (only implements TCM) and  
> ListModel (extends CollectionModel, implements TSM), then non-List  
> collections, i.e. all Sets will no longer expose size, i.e. they won't
> work with the ?size built-in. Also, they previously could be used for
> sequence concatenation with + operator, and that too will no longer  
> work.

Good point. My quick hunch is that we just should to add
TemplateSetModel... in 2.4.

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel