[OpenLayers-Dev] 2.10 and 2.11-RC1 OpenLayers.Class behavior changes

[RICHARD Didier]

> On Sun, Aug 7, 2011 at 12:01 AM, Eric Lemoine
> <eric.lemoine at camptocamp.com> wrote:
>> On Sat, Aug 6, 2011 at 9:32 PM, RICHARD Didier <didier.richard at ign.fr>
>> wrote:
>>>
>>>>
>>>>>>>> 2/ in test 4, if you remove the initialize function from B and
>>>>>>>> overload
>>>>>>>> A,
>>>>>>>> the B constructor is still the previous A's constructor.
>>>>>>>
>>>>>>> Yes. To address this one I see no other solution than patching
>>>>>>> OpenLayers.Class. See the patch attached to this email, and my
>>>>>>> test_overload_5 test function. The Class.html tests continue to
>>>>>>> pass
>>>>>>> with my patch.
>>>>>>>
>>>>>>
>>>>>> this works in OL 2.11, not in OL 2.10 for me !-(
>>>>>> I guess there is something similar to do in OL 2.10 ?
>>>>>
>>>>> Your initial mail was about OpenLayers trunk/2.11 introducing
>>>>> regressions. Now the failing test that remains is OL 2.10-only, so OL
>>>>> trunk/2.11 works better than OL 2.10 for you. Yippee! :-)
>>>>>
>>>>
>>>> My initial mail was really about regression between 2.10 and 2.11 !-)
>>>>
>>>>> (Not sure it is worth "fixing" OL 2.10 for that.)
>>>>>
>>>>
>>>> Well, one of my test is versus the current release (2.10) and I am
>>>> sure
>>>> there are users that will migrate slower than us (I mean OL and IGNF)
>>>> ...
>>>>
>>>> I do think it is worth fixing it ... at least to prove there is no
>>>> regression !-D
>>>>
>>>
>>> I've got somethinf working, hence ugly :-)
>>>
>>>    OpenLayers.overload= function(P,F) {
>>>        var pProtoInitialize= typeof(F.initialize)=="function"?
>>>            P.prototype.initialize
>>>        :   null;
>>>        OpenLayers.Util.extend(P.prototype, F);
>>>        if (pProtoInitialize!==null) {
>>>            // override sub-class having same constructor:
>>>            for (var pn in P) {
>>>                if (typeof(P[pn])=='function' &&
>>> P[pn].prototype.initialize===pProtoInitialize) {
>>>                    var f= {};
>>>                    eval('f=
>>> {"initialize":'+F.initialize.toString()+'}');
>>>                    P[pn]= OpenLayers.overload(P[pn],f);
>>>                }
>>>            }
>>>        }
>>>
>>>        return P;
>>>    };
>>
>> Hi Didier. Just to say that I personally wouldn't rely on an overload
>> function that assumes subclasses use their parent constructors as
>> their namespaces.
>
> I can't imagine a clean/correct implementation of your "overload"
> function that would make test_overload_5 pass with 2.10. If we apply
> the OL patch that I've proposed we can address this test case in 2.11
> (or 2.12). I still don't understand if that would be ok for you.
>
>
>    function test_overload_5(t) {
>        // overload constructor of parent class
>        t.plan(1);
>        var A = OpenLayers.Class({
>            initialize: function() {
>                this.a = "foo";
>            }
>        });
>        var B = OpenLayers.Class(A, {});
>        A = overload(A, {
>            initialize: function() {
>                this.a = "bar";
>            }
>        });
>        var b = new B;
>        t.eq(b.a, "bar", "ctor overloaded");
>    }
>

Hi Eric,

With your proposed patch, I am very happy (for the moment, my tests are
working, but I still have some issues --surely be related to 2.10 to 2.11
port in our Geoportal's API--).

If your patch is included in 2.11, it would be great.

For the 2.10 case, if I am the only one that takes care of that, then it
is not an OpenLayers's community issue !-)

Regards,

didier

>
> --
> Eric Lemoine
>
> Camptocamp France SAS
> Savoie Technolac, BP 352
> 73377 Le Bourget du Lac, Cedex
>
> Tel : 00 33 4 79 44 44 96
> Mail : eric.lemoine at camptocamp.com
> http://www.camptocamp.com
>


-- 
RICHARD Didier - Chef du pôle technique du Géoportail
2/4, avenue Pasteur - 94165 Saint Mandé Cedex
Tél : +33 (0) 1 43 98 83 23