Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: [Discussion] Bad idea to extend Date

  1. #1
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    299

    Default [Discussion] Bad idea to extend Date

    Hi.

    Ext uses its own namespace (which is a good thing as the jQuery folks tell you) for nearly everything. But there are two exceptions: Array and Date.
    In my project I use DateJS which extends the Date object using prototype just like Ext does. Now, the Date object behaves differently if I include DateJS before the inclusion of Ext than the other way round.

    But there's another problem: When a new browser will implement a method Ext now defines (like Date.format) Ext will overwrite the default behaviour so that other libraries will have problem.

    Remember: This is a real problem: The library Prototype has had problems after Firefox 3.0 implements a DOM method which Prototype has defined but which reacts differently. Prototype has had to rename his method so that JS code which uses this might break with Firefox 3.0...

    So in short: Extending base objects (DOM, Date, Array) is a very dangerous and bad thing.

    So my suggestion is that Ext uses its own Date object (Ext.Date) or uses method names which must be named like "Date.extJSFormat" insteadof "Date.format".

    What do you think?

    J

  2. #2
    Sencha User mystix's Avatar
    Join Date
    Mar 2007
    Location
    Singapore
    Posts
    6,236

    Default

    if you're specifically looking for datejs - extjs integration, this datejs google groups thread should help you:
    http://groups.google.com/group/datej...43b2eb7372405c

    i disagree with namespacing the Date methods just to avoid conflicts with other libraries which also augment the Date object though. i believe "adapters" would be better suited to this purpose. you're essentially postponing the issue since some other library at one point or another is bound to augment one of the core javascript objects (like Array / Date etc) eventually.

    [edit]
    p.s. Datejs also augments the core js Date object.
    what would you do if you had to use a non-Ext js library which also augmented the core js Date object?

  3. #3
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    299

    Default

    Quote Originally Posted by mystix View Post
    if you're specifically looking for datejs - extjs integration, this datejs google groups thread should help you:
    http://groups.google.com/group/datej...43b2eb7372405c

    i disagree with namespacing the Date methods just to avoid conflicts with other libraries which also augment the Date object though. i believe "adapters" would be better suited to this purpose. you're essentially postponing the issue since some other library at one point or another is bound to augment one of the core javascript objects (like Array / Date etc) eventually.

    [edit]
    p.s. Datejs also augments the core js Date object.
    what would you do if you had to use a non-Ext js library which also augmented the core js Date object?
    Please read my text completly. DateJS is just an example of the problem. The other problem is that new browsers may implement a Date.format method by its own. This would break the functionality.
    Please look at the ideas behind jQuery. The developer simply says that extending the browsers core objects is a bad idea. He's right - just look for the problems Prototype has with Element.getElementsByClass.

  4. #4
    Sencha User mystix's Avatar
    Join Date
    Mar 2007
    Location
    Singapore
    Posts
    6,236

    Default

    i did read your text completely.

    i'm posing a theoretical (albeit realistic) question, using datejs as an example:
    what would/should any library author do if their library augmented core js objects, and some of these methods were later implemented by some browser's js engine? what would be the best way to handle this other than namespacing? are there better alternatives to namespacing, or would namespacing be the solution?

    [edit]
    namespacing, as opposed to augmentation, would also likely result in more verbose code.
    this point might be moot since we could always set up some kind of internal shortcut like
    Code:
    (function() {
    var $ = Ext.Date;
    
    // other code here
    })();
    but that's still a fair bit more to write as opposed to simply calling methods on an actual js Date object, for example.

  5. #5
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    299

    Default

    Quote Originally Posted by mystix View Post
    but that's still a fair bit more to write as opposed to simply calling methods on an actual js Date object, for example.
    Correct. You have to rewrite your code BUT it would not break functionality with other libararies which uses prototype or with new browsers. So, I think it would be a need to have for 2.2 or 3.0.

    P.S.: I dislike the DateJS approach, too.

  6. #6
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    299

    Default

    Any update to this? I think it's a huge design failure and I would like to see a change for the next version of Ext JS.

  7. #7

    Default

    Quote Originally Posted by jheid View Post
    Any update to this? I think it's a huge design failure and I would like to see a change for the next version of Ext JS.
    Do you also advocate namespacing the augments to Function, Number and String?

    --dan

  8. #8
    Sencha User mystix's Avatar
    Join Date
    Mar 2007
    Location
    Singapore
    Posts
    6,236

    Default

    Quote Originally Posted by dantheman View Post
    Do you also advocate namespacing the augments to Function, Number and String?

    --dan
    funny. i was just thinking what a bother everything would be if everything had to be namespaced -- we'd lose the power of this...

  9. #9
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    299

    Default

    Quote Originally Posted by dantheman View Post
    Do you also advocate namespacing the augments to Function, Number and String?

    --dan
    Yes. Can't you image that a newer version of JavaScript could support a method like "defer"?

  10. #10
    Ext User deanna's Avatar
    Join Date
    Aug 2007
    Location
    Alabama
    Posts
    306

    Default

    While namespacing is a good idea, do you have to create an ExtDate object? Couldn't you do it by namespacing within the JS object. Date.Ext.functionName();

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •