1. #1

    Default Why have two versions (short hand and long form) of so many methods and properties?

    Why have two versions (short hand and long form) of so many methods and properties?


    [I apologize if this has been discussed before, but I couldn't find it anywhere in the forums after a few searches...]

    Given that a JavaScript library should be as small, fast and lean as possible...

    Why are there two versions of so many methods and functions?

    Just one example: the Observable "on" method is just as clear if not clearer than "addListener", and having two different versions actually confuses things a bit for me (I get so used to reading ExtJS code where people use "on" that if I see an "addListener" there is a slight mental hiccup before I realized that they were the same thing...) This also violates the DRY principle (http://en.wikipedia.org/wiki/DRY) somewhat...

    I can understand that "cm", "sm" and so on in the GridPanel are somewhat cryptic when compared to "colModel", "selModel"-- but even with these, you get the hang of it after dealing with the short form a few times.

    It's also a little daunting when looking at API docs, to see dozens of available properties available in certain classes. Having two forms for some of them just adds to the confusion and overall weight of the API..

    I propose that you just flat out get rid of all the long forms and go with the short forms on everything. This would make the library a bit smaller and a tiny bit faster too. If that's too big of a step, you could make a separate build that has the long forms removed. So people would have the option of using the smaller, leaner version of ExtJS...

    You could also do this in stages if it's too painful-- make some properties and methods be deprecated and clearly show them that way in the API docs for awhile until everyone gets used to them being deprecated, and then pull them out in some future version.

    Thoughts?

  2. #2
    Sencha User vmorale4's Avatar
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    189
    Vote Rating
    1
    vmorale4 is on a distinguished road

      0  

    Default


    Quote Originally Posted by Arthur.Blake View Post
    Why are there two versions of so many methods and functions?

    Just one example: the Observable "on" method is just as clear if not clearer than "addListener"

    I think this is related to the fact that Ext began its life as a YUI extension. If you are not familiar with YUI, its API sometimes is rather wordy. 'addListener' is one of those methods inherited from YUI.

  3. #3

    Default


    Sure... I can understand that. But going forward-- why not change it?
    Probably my #1 issue with ExtJS is the size. It's so big (even with compression and Gzipping.) Having multiple versions of methods and properties is just extra baggage...

  4. #4
    Sencha User vmorale4's Avatar
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    189
    Vote Rating
    1
    vmorale4 is on a distinguished road

      0  

    Default


    I agree that from an architecture perspective having a single version of a method makes more sense; but I'm afraid that removing the "long" versions is not feasible at this point in time. Furthermore, you won't gain that much in terms of bytes saved.

    For examples the definition of the "on" method is this:

    PHP Code:
         Appends an event handler to an element.  Shorthand for {@link #addListener}.
         
    * @member Ext.EventManager
         
    * @method on
         
    */
        
    pub.on pub.addListener
    The best way to reduce download size is to use the 'Build your own Ext' tool (not working currently) to include only the features that you need.

    Of course careful design is important so that one doesn't fall prey of feature creep; otherwise you end up having to include the whole library
    Last edited by vmorale4; 22 Apr 2008 at 2:21 PM. Reason: typos

  5. #5

    Default


    Removing addListener would save 9 bytes per method call (method call to the long version that is-- although this would come down to about nothing with religious gzip compression.)

    Are you part of the Ext development team? I'd like to hear their take on it...

  6. #6
    Sencha User vmorale4's Avatar
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    189
    Vote Rating
    1
    vmorale4 is on a distinguished road

      0  

    Default


    I'm not, I was just trying to be helpful ... The reason why I think that the Ext team would not be able to remove the long versions is because I remember reading a similar discussion earlier about changing the event method signature to make it more consistent.

    In that thread Jack stated this:
    2. The most important reason - it would break all our code and everyone elses code. There's no way we can do that at this stage.

  7. #7
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,545
    Vote Rating
    64
    Animal is a jewel in the rough Animal is a jewel in the rough Animal is a jewel in the rough

      0  

    Default


    There's already enough noise about how difficult it all is without having configs known only as "sm" and "cm". People's heads would implode with the stress of it!

Thread Participants: 2