1. #1
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,557
    Vote Rating
    341
    LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of

      0  

    Default AbstractComponent - isDescendant vs isDescendantOf

    AbstractComponent - isDescendant vs isDescendantOf


    These two methods are functionally about the same...

    Are they both needed? Could one be an alias of the other?

    Code:
    Ext.define('Ext.AbstractComponent', {
        ...
        isDescendant: function(ancestor) {
            if (ancestor.isContainer) {
                for (var c = this.ownerCt; c; c = c.ownerCt) {
                    if (c === ancestor) {
                        return true;
                    }
                }
            }
            return false;
        },
        ....
        /**
         * Determines whether this component is the descendant of a particular container.
         * @param {Ext.Container} container
         * @return {Boolean} `true` if the component is the descendant of a particular container, otherwise `false`.
         */
        isDescendantOf: function(container) {
            return !!this.findParentBy(function(p){
                return p === container;
            });
        },
        ...

  2. #2
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,557
    Vote Rating
    341
    LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of

      0  

    Default


    Is it possible to remove isDescendant (since it's a private method) and use only isDescendantOf?

  3. #3
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,557
    Vote Rating
    341
    LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of

      0  

    Default


    You guys say: Don't be afraid of the source code!

    But there's no answer when you ask a question.

  4. #4
    Sencha - Ext JS Dev Team evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    17,391
    Vote Rating
    709
    evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute

      0  

    Default


    They're slightly different. The public method checks the refOwner, whereas the private only explicitly checks ownerCt. It's used in a fairly performance critical part of the code, which is probably why it's separated out.
    Evan Trimboli
    Sencha Developer
    Twitter - @evantrimboli
    Don't be afraid of the source code!

  5. #5
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,557
    Vote Rating
    341
    LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of LesJ has much to be proud of

      0  

    Default


    Quote Originally Posted by evant View Post
    They're slightly different. The public method checks the refOwner, whereas the private only explicitly checks ownerCt. It's used in a fairly performance critical part of the code, which is probably why it's separated out.
    If these methods are functionally the same (but have a slightly different implementation), would it make sense to remove the slower method to avoid code duplication?

Thread Participants: 1