1. #1
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,483
    Vote Rating
    218
    LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold

      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,483
    Vote Rating
    218
    LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold

      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,483
    Vote Rating
    218
    LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold

      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,169
    Vote Rating
    674
    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,483
    Vote Rating
    218
    LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold

      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