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

[Eric Lemoine]

> Hi Eric,

Hi Didier

I have added tests for your usage patterns. See
<http://trac.osgeo.org/openlayers/changeset/12211>.

> 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.

I think it'd be safe to include it. Here's the ticket:
<http://trac.osgeo.org/openlayers/ticket/3454>. The patch is attached
to it.

But I'd like to bring something to your attention: my patch works
because the constructor passed to "overload" (which I renamed
"overwrite" in the tests) and the constructor returned by "overload"
share the same prototype object (See code below). And what's important
to know if that a closure is created in OpenLayers.Class when defining
the constructor function, this closure will prevent the garbage
collector from reclaiming the memory associated to constructors
overwritten by the "overload" function. I don't think that's a big
deal if you don't overwrite too many OpenLayers constructors in the
GeoPortal library.



    function test_overwrite_5(t) {
        // overwrite constructor of parent class, which itself
        // doesn't defined "initialize"
        t.plan(2);
        var A = OpenLayers.Class({
            initialize: function() {
                this.a = "foo";
            }
        });
        var B = OpenLayers.Class(A, {});
        var _A = A;
        A = overwrite(A, {
            initialize: function() {
                this.a = "bar";
            }
        });
        var b = new B;
        t.ok(A.prototype === _A.prototype, "A and _A share the prototype");
        t.eq(b.a, "bar", "ctor overwritten");
    }

-- 
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