Class mutators order-dependent #2216

Closed
ibolmo opened this Issue Jan 19, 2012 · 4 comments

Comments

Projects
None yet
4 participants
Owner

ibolmo commented Jan 19, 2012

(from Lighthouse)

Class::implement is looping through properties and evaluating class mutators as they are encountered now, which means that the mutations will have different results depending on order (i.e. putting Implements at the end will overwrite the Class methods). There are many side effects of this. Almost all JavaScript engines loop through object literals in order of definition, however that is not a part of the standard.

I propose moving the mutations before calling implement() in the Class function:

function Class(params){

    if (params instanceof Function) params = {initialize: params};

    var newClass = function(){
        Object.reset(this);
        if (newClass._prototyping) return this;
        this._current = $empty;
        var value = (this.initialize) ? this.initialize.apply(this, arguments) : this;
        delete this._current; delete this.caller;
        return value;
    }.extend(this);

    for (var mutator in Class.Mutators){
        if (!params[mutator]) continue;
        var value = Class.Mutators[mutator].call(params, params[mutator]);
        if (value == null) delete params[mutator];
    }

    newClass.implement(params);

    newClass.constructor = Class;
    newClass.prototype.constructor = newClass;

    return newClass;

};

This will make mutators work consistently independent of order (unless they literally conflict with each other) and give the mutators access to all the Class's params whereas before they only have access to whatever had been looped through already and attached to the prototype.

Owner

ibolmo commented Jan 19, 2012

Yep, I saw the history and I want to revive it.

I think that I'm with scott to run the mutators first.

On Thu, Jan 19, 2012 at 5:57 AM, Arian Stolwijk <
reply@reply.github.com

wrote:

It was marked as wontfix:
https://mootools.lighthouseapp.com/projects/2706/tickets/642#ticket-642-10


Reply to this email directly or view it on GitHub:
#2216 (comment)

Do you want me to make this change or can the issue be closed?

Member

fakedarren commented Feb 20, 2013

Closing as it's wontfix

fakedarren closed this Feb 20, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment