Lately we have witnessed some repeated Prototype criticism in the thread about Fork by Peter Michaux. Some other developers expressed their concerns that they shared with Peter - the same concerns that I keep hearing over and over in the past few months. Basically they can be summed up to these points: 1) it augments Number, String, Array, HTMLElement and Function prototype 2) it is not namespaced 3) its Event module is not robust enough 4) Enumerable module is slow / is strange / sucks (pick any of these) 5) strange inheritance scheme [1] 6) Sam is not addressing the public enough or acknowledging contributions 7) it doesn''t have official/up-to-date documentation In the following paragraphs I''m going to debunk these. I''m nothing more than a Prototype contributor and enthusiast who, at one point, almost ditched Prototype and created a fork (hybrid of YUI, mootools and Prototype) for his personal use, but then recent updates proved things were still rolling and won my attention back. Since then I dedicated my spare time to try and make Prototype better instead of creating yet another spinoff. So, here we go. I''ll try to keep it as short as possible. References can be found on the bottom. -------------------- 1) augment *.prototype - JavaScript is based on dynamic prototypal inheritance and object prototypes are available for writing with a reason. This way we can add utility methods directly to objects we need them to operate on. That is true OOP and that is what Rails does to Ruby built-in types without anyone crying about it. Instead, people love it. It makes the code shorter, operations more concise and the whole thing is easier to remember. People are actually afraid only of Array.prototype augmentation, because they have been using them as associative arrays all this time. This is wrong [2], so stop it. When you look at what Prototype does with a mind unclouded with fear, you''ll see that Number, String and Function extensions are sweet, new Array methods are great, and that was it does to extend DOM elements is brilliant. -------------------- 2) namespace - Prototype is, in fact, somehow namespaced. Its modules are namespaced, to be exact: DOM stuff is in Element, xmlHttpRequest in Ajax, and so on. There is no global namespace because it doesn''t fit in with its philosophy - Prototype is a low-level framework aimed at making coding easier, not a nightmare. It also extends built-in objects and you can''t namespace _that_. Some of you say "it doesn''t play along nicely with other frameworks". I fail to see effort to "play along nicely" in other frameworks except packing it all in a single namespace. If you want to namespace Prototype for your project that uses YUI, MochiKit and Dojo at the same time, you can easily do it by hand by taking 20 minutes of your time in a text editor. But in the end, using multiple frameworks will inevitably lead to feature duplication. YUI has everything namespaced, and everyone likes YUI. But everyone hates writing "YUI.namespace.module.bla.foo.bar()" to access a function. So what do people do? They bring often used functions to the global namespace and name them conveniently. In Prototype, you don''t have to undertake effort to have that kind of convenience. -------------------- 3) Event module - True, it is pretty basic right now. It doesn''t do scope correction, work around Safari bugs, or provide the ability to remove all the observers from an element... Or does it?? See ticket #5786 [3] by Andrew and me that brings all this to Event, and more. This is open source. When you miss a feature you can either whine about how YUI is better on your blog, or you can pull up your sleeves and get it done. Event module is more than usable right now and is getting better, so it is certainly no reason to ditch Prototype, unless you are making a GMail-killer app or something on that scale. -------------------- 4) Enumerable - Iterating over Hashes, Ranges and Arrays in Prototype is awesome! It reduces lengthy code full of endless loops and closures you can easily get lost in otherwise. It comes at a price, though - speed. Yes, using "each()" and friends (they all use "each" internally) can considerably slow your loop. There is a benchmark [4] by Marius Feraru; run it, observe the results. OK, let''s power on our common sense now. Exactly how much iterations are we going to need, anyway, and at what rate? The benchmark shows that, roughly, I can iterate over an array with a 1000 elements about 100 times in a second. That''s not at all slow - it is fast! I can have an array of 1000 HTML elements and iterate over all of them in just 10 milliseconds. Your common sense should tell you by now that most of the time you won''t even have a 1000 elements in an array. You will iterate over 5, 10, 20, sometimes 50 elements. I''m talking about more than 90% percent of all cases here - in a big app when speed is critical, you can always write an ordinary loop - who''s stopping you? But in all other cases, you can have the sweet, sweet sugar of Enumerable. It gets better. The ticket #6650 [5] proposes a speedup of Enumerable methods by using JavaScript forEach (currently implemented in Firefox 1.5). There is another thing - remember how you can throw $break and $continue in an iterable? Do you know that for N iterations you need 1 try/catch block for $break, but N of those blocks for $continue? Do you know that you can continue with an ordinary return statement, and that dropping $continue support in favor of return can speed up all iterations by almost 40% percent? I''ll be posting a patch for this soon. For people worried about Hash implementation, see #6649 [13]. If the patch gets applied you will be able to iterate over functions, use less memory and have a "safe" type of Hash that you can store anything into. -------------------- 5) class inheritance - Currently Prototype utilizes Class.create() and Object.extend() to get things done. Why do people have a problem with this? OK, we''re quite aware that this doesn''t scale, but it served us so well all this time and it''s going to get much better in Prototype 2.0 [6]. Remember, the "all-mighty" and powerful YUI doesn''t have a class inheritance scheme other than native JavaScript prototype inheritance and manually juggling the prototype objects around when subclassing ... But it still works and scales [7] pretty well, doesn''t it? -------------------- 6) Sam Stephenson - I admit I too miss having him around the list or ticket discussions, but if people willingly fill in for him than this is not a problem. And people are doing that - Justin Palmer is blogging about Prototype development and roadmap [8] (something Sam clearly doesn''t have time for) and Thomas Fuchs (madrobby) is doing a great job going through tickets, commenting and applying tested patches regularly. Sam also occasionally pulls up his sleeves and applies a "flurry of updates" [9] which alone is worth subscribing to the RSS log [10] because there are awesome gems in there. Regarding patches lingering about for too long: this is not because Sam or Thomas are lazy or indecisive. It is because patches are being submitted in poor quality and/or without tests. Like in Rails, tested, quality patches get applied sooner. -------------------- 7) API documentation - in the works [11]. Until released, read Justin Palmer [8] and other resources [12] which served us so well all this time. Documentation existed all this time, only it wasn''t centralized or written by Sam so people didn''t realize it. -------------------- *Whew* There it is - all points covered. Currently the only thing I don''t like in Prototype codebase is the Insertion API and small things that pollute the global namespace like Toogle.display() and Try.these(). But I have yet to come across a JavaScript framework that matches the power of DOM manipulations in Prototype. Form serialization is robust, Ajax is powerful but still easy to use, and the Trac is full of ready patches that just wait being decided on. All this is covered by tests built on a JavaScript unit test library. Comments/questions appreciated. Please be short and to the point - there are a lot of things that can be discussed here. Please don''t troll or point out to other frameworks. And please point out to valid points of criticism I''ve missed. Just don''t whine - make it work. (And contribute.) -- Mislav references: [1] http://encytemedia.com/blog/articles/2006/5/23/prototype-inheritance-madness [2] http://www.andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/ [3] http://dev.rubyonrails.org/ticket/5786 [4] http://gfx.neohub.com/benchmark/t/loops.html [5] http://dev.rubyonrails.org/ticket/6650 [6] http://sam.conio.net/articles/better-inheritance-for-prototype [7] http://code.google.com/p/yui-ext/ [8] http://encytemedia.com/development [9] http://encytemedia.com/blog/articles/2006/9/5/the-flurry-continues-more-prototype-updates [10] http://dev.rubyonrails.org/log/spinoffs/prototype/src?format=rss [11] http://encytemedia.com/blog/articles/2006/10/31/prototype-a-call-for-documentation [12] http://del.icio.us/mislav/prototype.js+documentation [13] http://dev.rubyonrails.org/ticket/6649 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Mislav wrote:> In the following paragraphs I''m going to debunk these....Applause! Whistles! Good rebuttal.> 4) Enumerable - Iterating over Hashes, Ranges and Arrays in Prototype > is awesome! It reduces lengthy code full of endless loops and closures > you can easily get lost in otherwise. It comes at a price, though - > speed. Yes, using "each()" and friends (they all use "each" internally) > can considerably slow your loop. There is a benchmark [4] by Marius > Feraru; run it, observe the results.e.Just to add. The Enumerable methods really underscores one of Prototype''s philosophies: *Generally favor brevity, ease of creation, and ease of maintenance over speed.* I believe this is a very important part of forward-thinking web philosophy and I am excited to be able to contribute. --Ken --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Awesome. Great information, and I like and agree with your perspective. My hat is off! Thanks On 12/1/06, Mislav <mislav.marohnic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Lately we have witnessed some repeated Prototype criticism in the > thread about Fork by Peter Michaux. Some other developers expressed > their concerns that they shared with Peter - the same concerns that I > keep hearing over and over in the past few months. Basically they can > be summed up to these points: > > 1) it augments Number, String, Array, HTMLElement and Function > prototype > 2) it is not namespaced > 3) its Event module is not robust enough > 4) Enumerable module is slow / is strange / sucks (pick any of these) > 5) strange inheritance scheme [1] > 6) Sam is not addressing the public enough or acknowledging > contributions > 7) it doesn''t have official/up-to-date documentation > > In the following paragraphs I''m going to debunk these. I''m nothing more > than a Prototype contributor and enthusiast who, at one point, almost > ditched Prototype and created a fork (hybrid of YUI, mootools and > Prototype) for his personal use, but then recent updates proved things > were still rolling and won my attention back. Since then I dedicated my > spare time to try and make Prototype better instead of creating yet > another spinoff. > > So, here we go. I''ll try to keep it as short as possible. References > can be found on the bottom. > > -------------------- > > 1) augment *.prototype - JavaScript is based on dynamic prototypal > inheritance and object prototypes are available for writing with a > reason. This way we can add utility methods directly to objects we need > them to operate on. That is true OOP and that is what Rails does to > Ruby built-in types without anyone crying about it. Instead, people > love it. It makes the code shorter, operations more concise and the > whole thing is easier to remember. > > People are actually afraid only of Array.prototype augmentation, > because they have been using them as associative arrays all this time. > This is wrong [2], so stop it. When you look at what Prototype does > with a mind unclouded with fear, you''ll see that Number, String and > Function extensions are sweet, new Array methods are great, and that > was it does to extend DOM elements is brilliant. > > -------------------- > > 2) namespace - Prototype is, in fact, somehow namespaced. Its modules > are namespaced, to be exact: DOM stuff is in Element, xmlHttpRequest in > Ajax, and so on. There is no global namespace because it doesn''t fit in > with its philosophy - Prototype is a low-level framework aimed at > making coding easier, not a nightmare. It also extends built-in objects > and you can''t namespace _that_. > > Some of you say "it doesn''t play along nicely with other frameworks". I > fail to see effort to "play along nicely" in other frameworks except > packing it all in a single namespace. If you want to namespace > Prototype for your project that uses YUI, MochiKit and Dojo at the same > time, you can easily do it by hand by taking 20 minutes of your time in > a text editor. But in the end, using multiple frameworks will > inevitably lead to feature duplication. > > YUI has everything namespaced, and everyone likes YUI. But everyone > hates writing "YUI.namespace.module.bla.foo.bar()" to access a > function. So what do people do? They bring often used functions to the > global namespace and name them conveniently. In Prototype, you don''t > have to undertake effort to have that kind of convenience. > > -------------------- > > 3) Event module - True, it is pretty basic right now. It doesn''t do > scope correction, work around Safari bugs, or provide the ability to > remove all the observers from an element... Or does it?? See ticket > #5786 [3] by Andrew and me that brings all this to Event, and more. > > This is open source. When you miss a feature you can either whine about > how YUI is better on your blog, or you can pull up your sleeves and get > it done. Event module is more than usable right now and is getting > better, so it is certainly no reason to ditch Prototype, unless you are > making a GMail-killer app or something on that scale. > > -------------------- > > 4) Enumerable - Iterating over Hashes, Ranges and Arrays in Prototype > is awesome! It reduces lengthy code full of endless loops and closures > you can easily get lost in otherwise. It comes at a price, though - > speed. Yes, using "each()" and friends (they all use "each" internally) > can considerably slow your loop. There is a benchmark [4] by Marius > Feraru; run it, observe the results. > > OK, let''s power on our common sense now. Exactly how much iterations > are we going to need, anyway, and at what rate? The benchmark shows > that, roughly, I can iterate over an array with a 1000 elements about > 100 times in a second. That''s not at all slow - it is fast! I can have > an array of 1000 HTML elements and iterate over all of them in just 10 > milliseconds. > > Your common sense should tell you by now that most of the time you > won''t even have a 1000 elements in an array. You will iterate over 5, > 10, 20, sometimes 50 elements. I''m talking about more than 90% percent > of all cases here - in a big app when speed is critical, you can always > write an ordinary loop - who''s stopping you? But in all other cases, > you can have the sweet, sweet sugar of Enumerable. > > It gets better. The ticket #6650 [5] proposes a speedup of Enumerable > methods by using JavaScript forEach (currently implemented in Firefox > 1.5). There is another thing - remember how you can throw $break and > $continue in an iterable? Do you know that for N iterations you need 1 > try/catch block for $break, but N of those blocks for $continue? Do you > know that you can continue with an ordinary return statement, and that > dropping $continue support in favor of return can speed up all > iterations by almost 40% percent? I''ll be posting a patch for this > soon. > > For people worried about Hash implementation, see #6649 [13]. If the > patch gets applied you will be able to iterate over functions, use less > memory and have a "safe" type of Hash that you can store anything into. > > -------------------- > > 5) class inheritance - Currently Prototype utilizes Class.create() and > Object.extend() to get things done. Why do people have a problem with > this? OK, we''re quite aware that this doesn''t scale, but it served us > so well all this time and it''s going to get much better in Prototype > 2.0 [6]. Remember, the "all-mighty" and powerful YUI doesn''t have a > class inheritance scheme other than native JavaScript prototype > inheritance and manually juggling the prototype objects around when > subclassing ... But it still works and scales [7] pretty well, doesn''t > it? > > -------------------- > > 6) Sam Stephenson - I admit I too miss having him around the list or > ticket discussions, but if people willingly fill in for him than this > is not a problem. And people are doing that - Justin Palmer is blogging > about Prototype development and roadmap [8] (something Sam clearly > doesn''t have time for) and Thomas Fuchs (madrobby) is doing a great job > going through tickets, commenting and applying tested patches > regularly. Sam also occasionally pulls up his sleeves and applies a > "flurry of updates" [9] which alone is worth subscribing to the RSS log > [10] because there are awesome gems in there. > > Regarding patches lingering about for too long: this is not because Sam > or Thomas are lazy or indecisive. It is because patches are being > submitted in poor quality and/or without tests. Like in Rails, tested, > quality patches get applied sooner. > > -------------------- > > 7) API documentation - in the works [11]. Until released, read Justin > Palmer [8] and other resources [12] which served us so well all this > time. Documentation existed all this time, only it wasn''t centralized > or written by Sam so people didn''t realize it. > > -------------------- > > *Whew* There it is - all points covered. > > Currently the only thing I don''t like in Prototype codebase is the > Insertion API and small things that pollute the global namespace like > Toogle.display() and Try.these(). But I have yet to come across a > JavaScript framework that matches the power of DOM manipulations in > Prototype. Form serialization is robust, Ajax is powerful but still > easy to use, and the Trac is full of ready patches that just wait being > decided on. All this is covered by tests built on a JavaScript unit > test library. > > Comments/questions appreciated. Please be short and to the point - > there are a lot of things that can be discussed here. Please don''t > troll or point out to other frameworks. And please point out to valid > points of criticism I''ve missed. > > Just don''t whine - make it work. > (And contribute.) > > -- > Mislav > > > references: > [1] > > http://encytemedia.com/blog/articles/2006/5/23/prototype-inheritance-madness > [2] > > http://www.andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/ > [3] http://dev.rubyonrails.org/ticket/5786 > [4] http://gfx.neohub.com/benchmark/t/loops.html > [5] http://dev.rubyonrails.org/ticket/6650 > [6] http://sam.conio.net/articles/better-inheritance-for-prototype > [7] http://code.google.com/p/yui-ext/ > [8] http://encytemedia.com/development > [9] > > http://encytemedia.com/blog/articles/2006/9/5/the-flurry-continues-more-prototype-updates > [10] http://dev.rubyonrails.org/log/spinoffs/prototype/src?format=rss > [11] > > http://encytemedia.com/blog/articles/2006/10/31/prototype-a-call-for-documentation > [12] http://del.icio.us/mislav/prototype.js+documentation > [13] http://dev.rubyonrails.org/ticket/6649 > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Likewise, very well put. Again one of the main reasons we went with Prototype was the great support environment and the fact that we did not seem to have trouble getting the end result to work nicely. Deco On Dec 1, 2006, at 12:02 PM, Mark Holton wrote:> Awesome. Great information, and I like and agree with your > perspective. My hat is off! > Thanks > > > On 12/1/06, Mislav < mislav.marohnic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Lately we have witnessed some repeated Prototype criticism in the > thread about Fork by Peter Michaux. Some other developers expressed > their concerns that they shared with Peter - the same concerns that I > keep hearing over and over in the past few months. Basically they can > be summed up to these points: > > 1) it augments Number, String, Array, HTMLElement and Function > prototype > 2) it is not namespaced > 3) its Event module is not robust enough > 4) Enumerable module is slow / is strange / sucks (pick any of > these) > 5) strange inheritance scheme [1] > 6) Sam is not addressing the public enough or acknowledging > contributions > 7) it doesn''t have official/up-to-date documentation > > In the following paragraphs I''m going to debunk these. I''m nothing > more > than a Prototype contributor and enthusiast who, at one point, almost > ditched Prototype and created a fork (hybrid of YUI, mootools and > Prototype) for his personal use, but then recent updates proved things > were still rolling and won my attention back. Since then I > dedicated my > spare time to try and make Prototype better instead of creating yet > another spinoff. > > So, here we go. I''ll try to keep it as short as possible. References > can be found on the bottom. > > -------------------- > > 1) augment *.prototype - JavaScript is based on dynamic prototypal > inheritance and object prototypes are available for writing with a > reason. This way we can add utility methods directly to objects we > need > them to operate on. That is true OOP and that is what Rails does to > Ruby built-in types without anyone crying about it. Instead, people > love it. It makes the code shorter, operations more concise and the > whole thing is easier to remember. > > People are actually afraid only of Array.prototype augmentation, > because they have been using them as associative arrays all this time. > This is wrong [2], so stop it. When you look at what Prototype does > with a mind unclouded with fear, you''ll see that Number, String and > Function extensions are sweet, new Array methods are great, and that > was it does to extend DOM elements is brilliant. > > -------------------- > > 2) namespace - Prototype is, in fact, somehow namespaced. Its modules > are namespaced, to be exact: DOM stuff is in Element, > xmlHttpRequest in > Ajax, and so on. There is no global namespace because it doesn''t > fit in > with its philosophy - Prototype is a low-level framework aimed at > making coding easier, not a nightmare. It also extends built-in > objects > and you can''t namespace _that_. > > Some of you say "it doesn''t play along nicely with other > frameworks". I > fail to see effort to "play along nicely" in other frameworks except > packing it all in a single namespace. If you want to namespace > Prototype for your project that uses YUI, MochiKit and Dojo at the > same > time, you can easily do it by hand by taking 20 minutes of your > time in > a text editor. But in the end, using multiple frameworks will > inevitably lead to feature duplication. > > YUI has everything namespaced, and everyone likes YUI. But everyone > hates writing "YUI.namespace.module.bla.foo.bar()" to access a > function. So what do people do? They bring often used functions to the > global namespace and name them conveniently. In Prototype, you don''t > have to undertake effort to have that kind of convenience. > > -------------------- > > 3) Event module - True, it is pretty basic right now. It doesn''t do > scope correction, work around Safari bugs, or provide the ability to > remove all the observers from an element... Or does it?? See ticket > #5786 [3] by Andrew and me that brings all this to Event, and more. > > This is open source. When you miss a feature you can either whine > about > how YUI is better on your blog, or you can pull up your sleeves and > get > it done. Event module is more than usable right now and is getting > better, so it is certainly no reason to ditch Prototype, unless you > are > making a GMail-killer app or something on that scale. > > -------------------- > > 4) Enumerable - Iterating over Hashes, Ranges and Arrays in Prototype > is awesome! It reduces lengthy code full of endless loops and closures > you can easily get lost in otherwise. It comes at a price, though - > speed. Yes, using "each()" and friends (they all use "each" > internally) > can considerably slow your loop. There is a benchmark [4] by Marius > Feraru; run it, observe the results. > > OK, let''s power on our common sense now. Exactly how much iterations > are we going to need, anyway, and at what rate? The benchmark shows > that, roughly, I can iterate over an array with a 1000 elements about > 100 times in a second. That''s not at all slow - it is fast! I can have > an array of 1000 HTML elements and iterate over all of them in just 10 > milliseconds. > > Your common sense should tell you by now that most of the time you > won''t even have a 1000 elements in an array. You will iterate over 5, > 10, 20, sometimes 50 elements. I''m talking about more than 90% percent > of all cases here - in a big app when speed is critical, you can > always > write an ordinary loop - who''s stopping you? But in all other cases, > you can have the sweet, sweet sugar of Enumerable. > > It gets better. The ticket #6650 [5] proposes a speedup of Enumerable > methods by using JavaScript forEach (currently implemented in Firefox > 1.5). There is another thing - remember how you can throw $break and > $continue in an iterable? Do you know that for N iterations you need 1 > try/catch block for $break, but N of those blocks for $continue? Do > you > know that you can continue with an ordinary return statement, and that > dropping $continue support in favor of return can speed up all > iterations by almost 40% percent? I''ll be posting a patch for this > soon. > > For people worried about Hash implementation, see #6649 [13]. If the > patch gets applied you will be able to iterate over functions, use > less > memory and have a "safe" type of Hash that you can store anything > into. > > -------------------- > > 5) class inheritance - Currently Prototype utilizes Class.create() and > Object.extend() to get things done. Why do people have a problem with > this? OK, we''re quite aware that this doesn''t scale, but it served us > so well all this time and it''s going to get much better in Prototype > 2.0 [6]. Remember, the "all-mighty" and powerful YUI doesn''t have a > class inheritance scheme other than native JavaScript prototype > inheritance and manually juggling the prototype objects around when > subclassing ... But it still works and scales [7] pretty well, doesn''t > it? > > -------------------- > > 6) Sam Stephenson - I admit I too miss having him around the list or > ticket discussions, but if people willingly fill in for him than this > is not a problem. And people are doing that - Justin Palmer is > blogging > about Prototype development and roadmap [8] (something Sam clearly > doesn''t have time for) and Thomas Fuchs (madrobby) is doing a great > job > going through tickets, commenting and applying tested patches > regularly. Sam also occasionally pulls up his sleeves and applies a > "flurry of updates" [9] which alone is worth subscribing to the RSS > log > [10] because there are awesome gems in there. > > Regarding patches lingering about for too long: this is not because > Sam > or Thomas are lazy or indecisive. It is because patches are being > submitted in poor quality and/or without tests. Like in Rails, tested, > quality patches get applied sooner. > > -------------------- > > 7) API documentation - in the works [11]. Until released, read Justin > Palmer [8] and other resources [12] which served us so well all this > time. Documentation existed all this time, only it wasn''t centralized > or written by Sam so people didn''t realize it. > > -------------------- > > *Whew* There it is - all points covered. > > Currently the only thing I don''t like in Prototype codebase is the > Insertion API and small things that pollute the global namespace like > Toogle.display() and Try.these(). But I have yet to come across a > JavaScript framework that matches the power of DOM manipulations in > Prototype. Form serialization is robust, Ajax is powerful but still > easy to use, and the Trac is full of ready patches that just wait > being > decided on. All this is covered by tests built on a JavaScript unit > test library. > > Comments/questions appreciated. Please be short and to the point - > there are a lot of things that can be discussed here. Please don''t > troll or point out to other frameworks. And please point out to valid > points of criticism I''ve missed. > > Just don''t whine - make it work. > (And contribute.) > > -- > Mislav > > > references: > [1] > http://encytemedia.com/blog/articles/2006/5/23/prototype- > inheritance-madness > [2] > http://www.andrewdupont.net/2006/05/18/javascript-associative- > arrays-considered-harmful/ > [3] http://dev.rubyonrails.org/ticket/5786 > [4] http://gfx.neohub.com/benchmark/t/loops.html > [5] http://dev.rubyonrails.org/ticket/6650 > [6] http://sam.conio.net/articles/better-inheritance-for-prototype > [7] http://code.google.com/p/yui-ext/ > [8] http://encytemedia.com/development > [9] > http://encytemedia.com/blog/articles/2006/9/5/the-flurry-continues- > more-prototype-updates > [10] http://dev.rubyonrails.org/log/spinoffs/prototype/src?format=rss > [11] > http://encytemedia.com/blog/articles/2006/10/31/prototype-a-call- > for-documentation > [12] http://del.icio.us/mislav/prototype.js+documentation > [13] http://dev.rubyonrails.org/ticket/6649 > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/1/06, Mislav <mislav.marohnic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> [Opening a class] is true OOP and that is what Rails does to > Ruby built-in types without anyone crying about it. Instead, people > love it. It makes the code shorter, operations more concise and the > whole thing is easier to remember.The Ruby community does this and nobody else. It''s possible in Python, but it''s called monkeypatching and is considered a last-case option. I''ve been bitten doing this, so I''m twice shy.> People are actually afraid only of Array.prototype augmentation, > because they have been using them as associative arrays all this time.I''m against builtin prototype augmentation (henceforth prototype hacking) and I''ve never used array as an associative array. Because prototype hacking isn''t namespaced, doing it on objects that don''t belong to you leads to the potential of breaking other people''s code. With Object.prototype, the breakage is obvious and I was very happy to see that yanked in 1.4, but the problem with Array.prototype is more subtle. Brendan Eich and the ECMA working group are once again active, so we''ll start seeing changes to JavaScript. Array is ripe for improvement, so what happens if the language gets a builtin with the same name as a current prototype extension and a different signature? Will prototype change signature to match and break all the working prototype code? I expect not, I''d anticipate a wrapper function that would preserve signature. Now how does the rest of the javascript world deal with that? They obviously won''t be dealing with prototype legacy code so they can use the builtin just fine, but what happens when someone wants to use the scriptaculous autocompleter and pulls in prototype? What if you don''t fully control the final page environment? I''ll admit that the above scenario probably won''t happen because I''d expect the standards guys to be aware of prototype, but it could happen and the possibility is enough for me to delcare prototype hacking on objects you don''t own to be evil. There are workarounds like Dean Edwards'' iframe trick, so it should be possible to hack around situations like the above if you''re aware of the problem, but it wouldn''t ever be a problem in the first place if prototype hacking didn''t happen.> 2) namespace - Prototype is, in fact, somehow namespaced.The complainers seem to think that somehow it''s not... I don''t care about this because my stuff _is_ all namespaced, so I''ll leave it at that.> YUI has everything namespaced, and everyone likes YUI. But everyone > hates writing "YUI.namespace.module.bla.foo.bar()" to access a > function. So what do people do?I like MochiKit''s solution. If you control the page, you export everything so that you don''t have to keep typing the namespaces. If you''re writing something to be reused, you can namespace your calls to play along nicely with others. If you''re curious, I use TurboGears and MochiKit instead of Rails and prototype, so my position is probably a bit different from most subscribers. I started on prototype about a year ago, realized what Object.prototype extensions implied, and jumped ship. I''m on the list to keep tabs on scriptaculous. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 1, 2006, at 1:32 PM, Karl Guertin wrote:> > On 12/1/06, Mislav <mislav.marohnic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> [Opening a class] is true OOP and that is what Rails does to >> Ruby built-in types without anyone crying about it. Instead, people >> love it. It makes the code shorter, operations more concise and the >> whole thing is easier to remember. > > The Ruby community does this and nobody else. It''s possible in Python, > but it''s called monkeypatching and is considered a last-case option. > I''ve been bitten doing this, so I''m twice shy.FYI The Lasso community is also heavily OOP, although not a requirement with LASSO. Essentially, there is backwards compatibility to older scripting, but the migration to OOP has been rapid since version 8. Deco> >> People are actually afraid only of Array.prototype augmentation, >> because they have been using them as associative arrays all this >> time. > > I''m against builtin prototype augmentation (henceforth prototype > hacking) and I''ve never used array as an associative array. Because > prototype hacking isn''t namespaced, doing it on objects that don''t > belong to you leads to the potential of breaking other people''s code. > With Object.prototype, the breakage is obvious and I was very happy to > see that yanked in 1.4, but the problem with Array.prototype is more > subtle. > > Brendan Eich and the ECMA working group are once again active, so > we''ll start seeing changes to JavaScript. Array is ripe for > improvement, so what happens if the language gets a builtin with the > same name as a current prototype extension and a different signature? > Will prototype change signature to match and break all the working > prototype code? I expect not, I''d anticipate a wrapper function that > would preserve signature. Now how does the rest of the javascript > world deal with that? They obviously won''t be dealing with prototype > legacy code so they can use the builtin just fine, but what happens > when someone wants to use the scriptaculous autocompleter and pulls in > prototype? What if you don''t fully control the final page environment? > > I''ll admit that the above scenario probably won''t happen because I''d > expect the standards guys to be aware of prototype, but it could > happen and the possibility is enough for me to delcare prototype > hacking on objects you don''t own to be evil. There are workarounds > like Dean Edwards'' iframe trick, so it should be possible to hack > around situations like the above if you''re aware of the problem, but > it wouldn''t ever be a problem in the first place if prototype hacking > didn''t happen. > >> 2) namespace - Prototype is, in fact, somehow namespaced. > > The complainers seem to think that somehow it''s not... I don''t care > about this because my stuff _is_ all namespaced, so I''ll leave it at > that. > >> YUI has everything namespaced, and everyone likes YUI. But everyone >> hates writing "YUI.namespace.module.bla.foo.bar()" to access a >> function. So what do people do? > > I like MochiKit''s solution. If you control the page, you export > everything so that you don''t have to keep typing the namespaces. If > you''re writing something to be reused, you can namespace your calls to > play along nicely with others. > > If you''re curious, I use TurboGears and MochiKit instead of Rails and > prototype, so my position is probably a bit different from most > subscribers. I started on prototype about a year ago, realized what > Object.prototype extensions implied, and jumped ship. I''m on the list > to keep tabs on scriptaculous. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Grat, great post Mislav! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Mislav, Mislav wrote:> 1) augment *.prototype - JavaScript is based on dynamic prototypal > inheritance and object prototypes are available for writing with a > reason. This way we can add utility methods directly to objects we need > them to operate on. That is true OOP and that is what Rails does to > Ruby built-in types without anyone crying about it. Instead, people > love it. It makes the code shorter, operations more concise and the > whole thing is easier to remember.Rails and Prototype execute in two completely different environments. In Rails the code needed to extend these built-in classes is already on the server. With Prototype the added sugar has to be transmitted to the client. Also there could be an exotic browser bug related to the sugar code that is not detected during testing.> -------------------- > > 2) namespace - Prototype is, in fact, somehow namespaced. Its modules > are namespaced, to be exact: DOM stuff is in Element, xmlHttpRequest in > Ajax, and so on. There is no global namespace because it doesn''t fit in > with its philosophy - Prototype is a low-level framework aimed at > making coding easier, not a nightmare. It also extends built-in objects > and you can''t namespace _that_.I don''t think you can say that Prototype is "somehow namespaced" because it doesn''t define it''s own namespace and stick too it. If using many different namespaces is considered namespcing then all JavaScript is somehow namespaced. For no necessary reason functions are attached to the Element object (not Element.prototype) and these functions could have just as easily been in an object called ProtoElement. I can''t see how calling a library that augments built-in prototypes can be considered namespaced at all. That is the ultimate move against namespacing. A JavaScript library doesn''t have to be namespaced in green field projects but the decision could be regretted later when third party components are available but unusable do to the lack of namespacing. Of course, using a library without namespacing in a legacy code situation is asking for trouble.> YUI has everything namespaced, and everyone likes YUI. But everyone > hates writing "YUI.namespace.module.bla.foo.bar()" to access a > function.I don''t hate it. It isn''t fun like a circus ride but I do appreciate the benefits.> So what do people do? They bring often used functions to the > global namespace and name them conveniently. In Prototype, you don''t > have to undertake effort to have that kind of convenience.With a namespaced library the option is there for the developer to make the appropriate decision given the particular page being developed.> -------------------- > > 3) Event module - True, it is pretty basic right now. It doesn''t do > scope correction, work around Safari bugs, or provide the ability to > remove all the observers from an element... Or does it?? See ticket > #5786 [3] by Andrew and me that brings all this to Event, and more. > > This is open source. When you miss a feature you can either whine about > how YUI is better on your blog, or you can pull up your sleeves and get > it done. Event module is more than usable right now and is getting > better, so it is certainly no reason to ditch Prototype, unless you are > making a GMail-killer app or something on that scale.I hope the situation of user contributions to Prototype is improving.> -------------------- > > 4) Enumerable - Iterating over Hashes, Ranges and Arrays in Prototype > is awesome!I don''t think it is awesome. I think the syntax is clumsy. Having to define a function to run a loop is a major kludge to me.> It reduces lengthy code full of endless loopsIt doesn''t reduce code length by much http://peter.michaux.ca/article/48 and along with this minor reduction in loop lengths, much library code has to be downloaded to implement the sugar.> and closures you can easily get lost in otherwise.A experienced JavaScript developer coming to a project using Prototype for the first time will be confused by the iterators when for loops could have been used. I can easily see how this argument can be disregarded but the sugar iterators do not make loops look simpler to everyone.> It comes at a price, though - > speed. Yes, using "each()" and friends (they all use "each" internally) > can considerably slow your loop. There is a benchmark [4] by Marius > Feraru; run it, observe the results. > > OK, let''s power on our common sense now. Exactly how much iterations > are we going to need, anyway, and at what rate?With a slow computer and demanding animation or dragdrop behavior of complex structures I want to have as efficient code as possible during these operation. At these times you can stop using the sugar but right now the sugar is part of the underlying Prototype and Scriptaculous library so it is difficult to stop that sugar unless patches are accepted to Prototype and Scriptaculous.> It gets better. The ticket #6650 [5] proposes a speedup of Enumerable > methods by using JavaScript forEach (currently implemented in Firefox > 1.5).Unfortunately Firefox is probably only 10-20% of general users so for now and for some sort of relatively meaningless comparison multiply the savings/excitement by 0.2 at best. Also this means that you will have to have two versions of the sugar implementation. If JavaScript 1.7 catches on in other browsers then in about 5 years there will be real iterators available for use.> -------------------- > > 5) class inheritance - Currently Prototype utilizes Class.create() and > Object.extend() to get things done. Why do people have a problem with > this? OK, we''re quite aware that this doesn''t scale, but it served us > so well all this time and it''s going to get much better in Prototype > 2.0 [6]. Remember, the "all-mighty" and powerful YUI doesn''t have a > class inheritance scheme other than native JavaScript prototype > inheritance and manually juggling the prototype objects around when > subclassing ... But it still works and scales [7] pretty well, doesn''t > it?YUI has the best JavaScript inheritance mechanism I have encountered that gives the closest Ruby-like behavior possible. It is simple and reinforces the ideas of prototype based inheritance when a developer is using it. http://kevlindev.com/tutorials/javascript/inheritance/index.htm http://peter.michaux.ca/article/1 http://peter.michaux.ca/article/49 http://peter.michaux.ca/article/50> 7) API documentation - in the works [11].For me, one of the most valuable software development steps is the reflection and evaluation I must make when writing API documentation. It forces me to review the product of my work and if I cringe even a little when I am explaining any part of the API then I know I got it wrong. It is the time where I can see if the API as a whole is consistent. I think API documentation is probably more important then tests because fixing the internals later is easier then asking people to change their library calls.> *Whew* There it is - all points covered.But not debunked without tradeoffs that could be judged as unacceptable. Every library will have tradeoffs. For a long time I wanted and tried to like Prototype because it has the Rails stamp of approval and tight Rails integration but I just can''t make it work for me. That''s why I''ve gone my own way and started a new library for use with Rails that can just as easily be used outside of Rails and when I''m working with legacy code. Peter -------- http://forkjavascript.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Peter, What is it exactly that you are trying to do? Drive Prototype users away from Prototype to your own library? I''m sorry, but I''m starting to find your attitude slightly displeasing to say the least. If you do not like Prototype, don''t use it. If you have another library to offer, please feel free to promote it, but are you sure it is necessary to bash on Prototype to do so? Regards, Tobie -- Tobie Langel http://tobielangel.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/3/06, tobie <tobie.langel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Peter, > > What is it exactly that you are trying to do? Drive Prototype users > away from Prototype to your own library?He has the right to criticize the framework. His points are valid, although he sounds like the library is completely hopeless - that''s the part I don''t like. With Prototype the added sugar has to be transmitted to the client. Also> there could be an exotic browser bug related to the sugar code that is not > detected during testing.Since when do we fear browser bugs? We will work around them About namespacing, see my most recent thread. I''d like you to leave a comment on it... A experienced JavaScript developer coming to a project using Prototype for> the first time will be confused by the iterators when for loops could have > been used.That was me. I didn''t understand Enumerable until Justin blogged about it. I found it strange at first - now I love it. You have to be open minded. About the bottlenecks, we''ll try to work on it. For large arrays and huge number of loops I revert to using for loops, but that''s very rare. YUI has the best JavaScript inheritance mechanism I have encountered> that gives the closest Ruby-like behavior possible. It is simple and > reinforces the ideas of prototype based inheritance when a developer > is using it.I don''t see why Prototype doesn''t. It just has sugar added to it - Class.create(), Object.extend() That''s why I''ve gone my own way and started a new library for use with Rails> that can just as easily be used outside of Rails and when I''m working with > legacy code.I''ve been reading your blog since before Fork. Your level of JavaScript knowledge is admirable. Perhaps with all that ideas how to make a better framework you can certainly come up with occasional patches/suggestions for the Prototype framework on the ticket system, too? It''s far from hopeless, believe me ;) -- Mislav --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Tobie, On 12/3/06, tobie <tobie.langel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > What is it exactly that you are trying to do?The Rails world has a bad practice of promoting only the positives. This misleads people. Rails gives Prototype the stamp of approval by default inclusion and the most some people might know about Prototype is <%= javascript_include_tag ''prototype'' %> If Prototype''s front page contained a link to a page describing design tradeoffs I think users evaluating the library''s worth and applicability would be much better served. The code shows these features in plain JavaScript so why not just tell them quickly in a little bit of plain English? If they find the tradeoffs acceptable then it doesn''t matter if they read them in JavaScript or English. It is just that the English will make the evaluation much faster. Also there are many clever Rails programmers that don''t know even intermediate JavaScript and eventhough they would understand the tradeoffs as concepts if written in English they can''t see them when reading the Prototype code directly.> Drive Prototype users away from Prototype to your own library?No.> I''m sorry, but I''m starting to find your attitude slightly displeasing > to say the least. > > If you do not like Prototype, don''t use it. If you have another library > to offer, please feel free to promote it, but are you sure it is > necessary to bash on Prototype to do so?I think Rails users should be warned of the potential serious consequences of using Prototype and investing time into learning to write JavaScript with the Prototype way when that invested time would be better spent learning how to write and understand usual JavaScript. They will need these skills when they try and create a unique UI. Peter ------- http://forkjavascript.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Mislav, On 12/3/06, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> On 12/3/06, tobie <tobie.langel@gmail.com> wrote: > > > > Peter, > > > > What is it exactly that you are trying to do? Drive Prototype users > > away from Prototype to your own library? > > He has the right to criticize the framework. His points are valid, although > he sounds like the library is completely hopeless - that's the part I don't > like.It is not completely hopeless. Prototype/Scriptaculous might be fine for a green field project that will never use third party JavaScript. I was taught to never say never.> > With Prototype the added sugar has to be transmitted to the client. Also > there could be an exotic browser bug related to the sugar code that is not > detected during testing. > > Since when do we fear browser bugs? We will work around themWe should fear browser bugs. We can only work around the ones we know about but we don't want to need to revisit working websites when a new bug appears if we can help it. Adding unnecessary code only increases the "length of the chain" and the chance of a weak link. It is true that the Prototype sugar mostly involves only JavaScript 1.5 features and not host objects. It is reasonable to expect that a browser can execute the JavaScript language and so the sugar should not have problems. However I think maintaining concise code that uses "short chains" is a wiser approach over all.> > A experienced JavaScript developer coming to a project using Prototype for > the first time will be confused by the iterators when for loops could have > been used. > > That was me. I didn't understand Enumerable until Justin blogged about it. I > found it strange at first - now I love it. You have to be open minded.I was open minded and after looking at the tradeoffs I made a choice. It seems being decided and opposite to someone elses decision equals closed minded. <shrug> With Enumerable you get a different way of thinking that may make you feel good when you program. However you get decreased performance, are tied to a particular library for basic language function, that library must be downloaded and any code maintainer must have knowledge of that library to maintain the derivative code. The decreased perfomance is the big hit for me. Why need several function calls, a function definition and a try catch block for each iteration when JavaScript has a for loop? I think this is working too hard to save only a few characters of code and to feel good. My job is to write the most robust code I can and the Enumerable stuff does not support that goal. DHH wrote a great April fools joke that I think applies to Prototype use of sugar http://www.loudthinking.com/arc/000582.html> About the bottlenecks, we'll try to work on it.The thing is you don't have to. Just use loops. Finished. The time could be better spent on fixing bugs and improving workarounds or refactoring other parts of Prototype.> For large arrays and huge > number of loops I revert to using for loops, but that's very rare. > > > YUI has the best JavaScript inheritance mechanism I have encountered > > that gives the closest Ruby-like behavior possible. It is simple and > > reinforces the ideas of prototype based inheritance when a developer > > is using it. > > I don't see why Prototype doesn't. It just has sugar added to it - > Class.create(), Object.extend() > > > > That's why I've gone my own way and started a new library for use with > Rails that can just as easily be used outside of Rails and when I'm working > with legacy code. > > I've been reading your blog since before Fork. Your level of JavaScript > knowledge is admirable. Perhaps with all that ideas how to make a better > framework you can certainly come up with occasional patches/suggestions for > the Prototype framework on the ticket system, too? It's far from hopeless, > believe me ;)You can watch YUI, Fork or any of the other libraries for workarounds and novel ideas with nice implementation and migrate those changes to Prototype. I want a namespaced library and so won't be spending my time writing patches particular to Prototype. I think someone needs to dive in and rewrite Prototype's implementation with more consistency and call it Prototype 2 with some API changes if necessary. In the rewrite, the Enumerable stuff could be provided but not actually used by the library itself so perfomances can be best when needed. Along the way all tradeoffs could be noted and consistent documentation written. For someone that understands all of Prototype well and another library like YUI this entire process might take a month. It would be huge improvement and users of Prototype would know what they are getting into when they start using. Peter ------- http://forkjavascript.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs@googlegroups.com To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
I totally agree. It''s completely unprofessional, and distracting to self-promote your own little framework the way that you are. It''s one thing to make people aware, it''s another to endlessly promote your own plus bash the existing community. It doesn''t do your code any favors either. Annoyed as well, Mark On 12/3/06, tobie <tobie.langel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Peter, > > What is it exactly that you are trying to do? Drive Prototype users > away from Prototype to your own library? > > I''m sorry, but I''m starting to find your attitude slightly displeasing > to say the least. > > If you do not like Prototype, don''t use it. If you have another library > to offer, please feel free to promote it, but are you sure it is > necessary to bash on Prototype to do so? > > Regards, > > Tobie > > -- > Tobie Langel > http://tobielangel.com > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Please, keep the discussion about Peter and Fork on his thread. This thread is strictly about Prototype, current problems and where it''s headed -M On 12/3/06, Mark Holton <holtonma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I totally agree. It''s completely unprofessional, and distracting to > self-promote your own little framework the way that you are. It''s one > thing to make people aware, it''s another to endlessly promote your own plus > bash the existing community. It doesn''t do your code any favors either. > Annoyed as well, > Mark--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 3, 2006, at 10:16 AM, Mislav Marohnić wrote:> Please, keep the discussion about Peter and Fork on his threadHow about on his own list? I''m preparing to unsubscribe from this list based on the level of noise that has popped up in the last week. Peter: Prototype and Scriptaculous got to be so widely used by being good (or good enough) to satisfy the needs of a great many people. I suggest you spend your time getting Fork to that point and gaining converts through illustrated merit rather than spending your time tirelessly evangelizing on a list that''s dedicated to the projects you''re advocating *against*. Enough already. -Clay -- Killersoft.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Agreed. His own list would be great. I want to hear about how people are making things happen with a library I enjoy -- Prototype + Scriptaculous On 12/3/06, Clay Loveless <clay@killersoft.com> wrote:> > > On Dec 3, 2006, at 10:16 AM, Mislav Marohnić wrote: > > > Please, keep the discussion about Peter and Fork on his thread > > How about on his own list? > > I'm preparing to unsubscribe from this list based on the level of > noise that has popped up in the last week. > > Peter: Prototype and Scriptaculous got to be so widely used by being > good (or good enough) to satisfy the needs of a great many people. I > suggest you spend your time getting Fork to that point and gaining > converts through illustrated merit rather than spending your time > tirelessly evangelizing on a list that's dedicated to the projects > you're advocating *against*. > > Enough already. > > -Clay > > -- > Killersoft.com > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs@googlegroups.com To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Exactly. That brings to my mind: http://dev.rubyonrails.org/report/21 (faults) http://dev.rubyonrails.org/report/22 (unprocessed patches) http://dev.rubyonrails.org/report/25 (untested patches) Everything you see there is waiting for comments and tests-- so, anyone, please go ahead... :) -Thomas Am 01.12.2006 um 19:15 schrieb Mislav:> Just don''t whine - make it work. > (And contribute.) > > -- > Mislav >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Am 01.12.2006 um 21:32 schrieb Karl Guertin:> Brendan Eich and the ECMA working group are once again active, so > we''ll start seeing changes to JavaScript. Array is ripe for > improvement, so what happens if the language gets a builtin with the > same name as a current prototype extension and a different signature? > Will prototype change signature to match and break all the working > prototype code? I expect not, I''d anticipate a wrapper function that > would preserve signature. Now how does the rest of the javascript > world deal with that? They obviously won''t be dealing with prototype > legacy code so they can use the builtin just fine, but what happens > when someone wants to use the scriptaculous autocompleter and pulls in > prototype? What if you don''t fully control the final page environment? > > I''ll admit that the above scenario probably won''t happen because I''d > expect the standards guys to be aware of prototype, but it could > happen and the possibility is enough for me to delcare prototype > hacking on objects you don''t own to be evil. There are workarounds > like Dean Edwards'' iframe trick, so it should be possible to hack > around situations like the above if you''re aware of the problem, but > it wouldn''t ever be a problem in the first place if prototype hacking > didn''t happen.What are you talking about? We''re not writing Prototype for some version of JavaScript that might or might not arrive years from now. If they really dare to break backwards compatibility, well, the worst thing that can happen is that we have to release a new version. I''m pretty sure browsers will still have release candidates and beta versions in the future, so there should be plenty of time to do so. I''d trade in having.to.write.long.lines() for concise code every day. -Thomas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Mark Holton wrote:> I totally agree. It''s completely unprofessional, and distracting to > self-promote your own little framework the way that you are.Peter was responding about Prototype to a thread entitled "The future of Prototype framework". His criticisms were valid and substantiated with suggestions for improvement. His only mention of Fork was in response to another post, his promotion of Fork was in an appropriately titled thread prefixed by "ANN:". You may note that the OP started the thread with: "Lately we have witnessed some repeated Prototype criticism in the thread about Fork by Peter Michaux." I think Peter is entitled to respond. If you have criticisms of Fork, let them be known or go to some other news group and air your views there. -- Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Great, great post, Mislav. I''d like to mention (once again) that nearly all criticism of Prototype falls into two categories: (1) Stuff it does that you don''t like (augmented prototypes, shallow namespacing, syntactic sugar). These are philosophy differences, and they are not subject to veto. Prototype tries to operate under the same general philosophy as Ruby, so if you don''t like that philosophy then there are other wonderful frameworks you can use instead. (2) Stuff that shows a lack of polish, or stuff that doesn''t reflect well on a community. (Lack of documentation, unprocessed patches, glaring bugs, little communication). I will acknowledge that Prototype has room to improve in this area. But that''s why we''re doing something about it. We''ve formed a Prototype Core development team *and* a documentation team. Thomas has done a great job of responding to patches and submitting bugfixes. And even though Sam is not very vocal: I am. Justin Palmer is. Thomas Fuchs is. Dan Webb is. We blog about Prototype all the time, and we''re able to give input into its long-term direction. If there''s some aspect of the the Prototype community (this mailing list, the IRC channel, and the blogs of Core members) that you find lacking, let one of us know. Don''t feel like you''re not being heard just because you don''t have Sam''s ear. Cheers, Andrew Dupont --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/4/06, Thomas Fuchs <t.fuchs-moWQItti3gBl57MIdRCFDg@public.gmane.org> wrote:> What are you talking about? We''re not writing Prototype for some version > of JavaScript that might or might not arrive years from now.Given that: 1. The language can change. I think ''years from now'' is unlikely but that''s not important to the argument. 2. Prototype hacking is not namespaced. I''m arguing that a future language change could conflict with an enhancement in Prototype. For example, let''s say that the standards group desides Array.each will take an array of arrays and appends the lhs array onto the end of all the arrays passed as arguments (this is a pretty dumb idea, but it''s just an example). The prototype maintainers either have to break compatibility with all the prototype code out there or have to break Array.each for everybody else. I don''t like the idea of my code breaking in the future (I make pages that wind up in public sector use, so an app running 6-7 years is not farfetched) nor do I like the idea of my choices causing someone else''s code to break. It''s the same scenario as javascript libraries clobbering each others'' prototype extensions but with the language itself instead of a library. I don''t think this scenario is very likely, but it does illustrate why I oppose prototype hacking on shared objects (Object, Date, Array, String, RegEx, etc). This is a response to the original assertion:> People are actually afraid only of Array.prototype augmentation, > because they have been using them as associative arrays all this time.I have never used arrays as associative arrays and I have a technical reason for rejecting prototype hacking. People are free to decide that scenarios like this are too remote to be worth considering for their projects, and I expect most prototype developers will, but that doesn''t mean my position is invalid.> I''d trade in having.to.write.long.lines() for concise code every day.I hate writing namespaced code and only do it when my code is likely to wind up in a mixed environment. I appreciate being able to make the decision. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 4, 3:25 pm, "Karl Guertin" <grayr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I don''t like the idea of my code breaking in the future ... > nor do I like the idea of my choices causing someone else''s code > to break.This won''t happen. There won''t be new stuff added to JavaScript until version 2, which will also include features like modules and namespacing to allow code to run on its own island. For example, a script will be able to use a copy of the "intrinsic" namespace (i.e., without whatever extensions have been applied by another script) if it wants. Any future standardizing of JS will take into account the difficulty of developing in a heterogeneous environment. There are two sorts of dangers that Prototype presents: the *pragmatic* sort (what if I have old scripts that do for..in on arrays, which Prototype breaks) and the *theoretical* sort (the footprint on the global namespace is not minimized, what if another script redefines String.prototype.capitalize incompatibly, etc.). I acknowledge that the pragmatic dangers are to be guarded from, but I simply am not terrified by the theoretical dangers. Some people are, and that''s fine. That''s why there''s Dojo, MochiKit, and YUI. But so far I''ve encountered *only one* pragmatic danger of using Prototype, and it''s a by-product of the incorrect code of third parties. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/4/06, Karl Guertin <grayrest-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > I''m arguing that a future language change could conflict with an > enhancement in Prototype.Future changes that modify public APIs in JavaScript will break any other code as well as Prototype''s. You''re talking about 6-7 years from now - imagine what browsers will look like then? You will have Firefox 6, Opera 12, Safari 4, IE 7.1 and a ton of new stuff that I''m not even trying to imagine. This is not Java where you deploy in a known environment - you''re deploying your script into the unknown and you cannot have that kind of security. You have to have unobtrusive code (if it fails, the application still works) that is maintained over time. I don''t think this scenario is very likely, but it does illustrate why> I oppose prototype hacking on shared objects (Object, Date, Array, > String, RegEx, etc).I don''t approve the usage of the term "hacking" when using a natural feature of the language. If we could "subclass" Array, Object, Date and others things would be different - unfortunately subclassing built-in types is a pain (Dean Edwards'' blog). Therefore we''re stuck with built-in types - at least we can enrich their APIs. Also I agree with Andrew Dupont. -- Mislav --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/4/06, Andrew Dupont <google-TiabPMV39B5K4mp1Ns0Z8Q@public.gmane.org> wrote:> I''d like to mention (once again) that nearly all criticism of Prototype > falls into two categories: > > (1) Stuff it does that you don''t like (augmented prototypes, shallow > namespacing, syntactic sugar). These are philosophy differences, and > they are not subject to veto.For the record, I do understand this and I have no desire to see prototype changed. I only intend to point out that the philosophy differences do not exist because people are ignorant, as implied by Mislav in the OP, but stem from people operating under different conditions. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
> You''re talking about 6-7 years from now - imagine what browsers will look like then? You will have Firefox 6, Opera 12, Safari 4, IE 7.1;-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/4/06, Karl Guertin <grayrest-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > I only intend to point out that the philosophy > differences do not exist because people are ignorant, as implied by > Mislav in the OP, but stem from people operating under different > conditions.Well said. I never really meant to imply that people are ignorant except in the case of associative usage of the Array object. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/4/06, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> On 12/4/06, Karl Guertin <grayrest@gmail.com> wrote: > > > > I'm arguing that a future language change could conflict with an > > enhancement in Prototype. > > Future changes that modify public APIs in JavaScript will break any other > code as well as Prototype's.I think the point is that being conservative and keeping to a namespace will reduce the chance of broken scripts when the JavaScript API is expanded.> You're talking about 6-7 years from now - > imagine what browsers will look like then? You will have Firefox 6, Opera > 12, Safari 4, IE 7.1:-)> I don't approve the usage of the term "hacking" when using a natural feature > of the language.If programming hacking is something that exists then it occurs within a language. To execute it must use the natural features of the language. So hacking uses the natural features of the language.> If we could "subclass" Array, Object, Date and others > things would be different - unfortunately subclassing built-in types is a > pain (Dean Edwards' blog). Therefore we're stuck with built-in types - at > least we can enrich their APIs.You can but it may not be pragmatic/prudent/wise knowing the language API will expand. This is similar to extending Object.prototype which will likely break other code. JavaScript lets you shoot yourself in the foot constently. Programmer discipline is required. Peter -------- http://forkjavascript.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs@googlegroups.com To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/4/06, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> I don't approve the usage of the term "hacking" when using a natural feature > of the language.I've called if prototype hacking for a while. I find it fits in with the general idea of doing something expedient that can possibly break.> This won't happen. There won't be new stuff added to JavaScript until > version 2, which will also include features like modules and > namespacing to allow code to run on its own island....[snip]> But so far I've > encountered *only one* pragmatic danger of using Prototype, and it's a > by-product of the incorrect code of third parties.That's reasonable enough. When I initially made the decision in JavaScript, Object.prototype was in use which was much less okay. My current opposition is more theoretical, but I have, as mentioned, seen a monkeypatch in Python backfire and cause a lot of problems for people. When javascript grows namespaces in all the popular browsers^W^W^W^WIE, consider my objection dropped. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs@googlegroups.com To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Mislav Marohnić wrote:> On 12/4/06, Karl Guertin <grayrest-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > I only intend to point out that the philosophy > > differences do not exist because people are ignorant, as implied by > > Mislav in the OP, but stem from people operating under different > > conditions. > > > Well said. I never really meant to imply that people are ignorant except in > the case of associative usage of the Array object.If that is so, then you must think whoever decided to extend the built-in Array object is also ignorant. If you don''t accept that (and clearly you don''t), then your criticism is completely without merit. The example of for..in is just the obvious case, the underlying issue is that once you extend a built-in object, it is no longer available in its original form. Anyone trying to create their own subclass, for whatever reason, is stuck with the extended object. They have a choice of accommodating the extensions or not using the library. It has been stated here that a primary goal of Prototype is to reduce the amount of code that a programmer must write, and that considerations such as execution speed and architectural cleanliness take a back seat. Now that is fine, but to generalise that anyone affected by that decision is ignorant is hardly reason argument. A much better response is to accept the shortcomings of Prototype, make sure people using the library are aware of them and work toward attenuating their effects, either by suggesting work-arounds or fixing them at the source. -- Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Rob, Using a for...in loop on an Array is bad practice / plain wrong (c.f. http://www.andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/). I wouldn''t call somewhat using it an ignorant... but the fact remains that he ignores that arrays should not be iterated over that way. Seriously, I don''t see how you can call that a shortcomings of Prototype. regards, Tobie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/4/06, RobG <rgqld-AFFH1GffN5hPR4JQBCEnsQ@public.gmane.org> wrote:> The example of for..in is just the obvious case, the underlying issue > is that once you extend a built-in object, it is no longer available in > its original form. Anyone trying to create their own subclass, for > whatever reason, is stuck with the extended object. They have a choice > of accommodating the extensions or not using the library.You seem to have missed their argument. It is laid out pretty clearly in the above posts and goes something like this: """ The only repeated problem reported by prototype.js users is for...in loops on Array. You can make arguments as to why a particular prototype.js design decision is bad, but we don''t hear about it causing problems. When it becomes a problem, we''ll fix it. Until then, practicality beats purity. """ Unless you have an actual case where prototype is causing a problem, reprimanding them on their design decisions is basically trolling. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
tobie wrote:> Rob, > > Using a for...in loop on an Array is bad practice / plain wrong (c.f.You ignored the bulk of my post - I''ll keep it simple. If a library adds properties to built-in objects, it should ensure that anyone using that library is aware of the extra properties and allows for them where necessary. A library that doesn''t extend built-in objects doesn''t have that problem.> Seriously, I don''t see how you can call that a shortcomings of > Prototype.You can regard it as a shortcoming or a feature, that point is moot. What you do have to acknowledge is that it is a fact and that users should be aware of it. When someone says "Oh, but library X extends Array, String, etc." you say yes, with these properties... and we deal with that like this... then it''s up to the questioner to make up their mind whether to continue with the library or not. -- Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hey Mislav, your post is really great and I think you pointed out what is really important if you use the prototype library. And since there was already much said, I wont add much. I''m using prototype for quite a long time now and not only for some client side aesthetics but for real applications and its great. The bad thing about prototype is the lack of centralized documentation (even if there is a try [1]), but the good thing and the main important point is that it behaves like you would expect it to do and this helps development and improves the productivity of the developer. Martin [1] http://encytemedia.com/blog/articles/2006/10/31/prototype-a-call-for-documentation --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Am 04.12.2006 um 22:57 schrieb Mislav Marohnić:> You''re talking about 6-7 years from now - imagine what browsers > will look like then? You will have Firefox 6, Opera 12, Safari 4, > IE 7.1Thanks for the laugh! :) -Thomas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---