Hello,
Is there a way to create regular javascript arrays when using
Prototype?
The problem is that I would like to integrate prototype to one of my
sites but it already uses lots of other pieces of javascript that use
the for (x in myArray)... construction. When using that kind of loop
over an array that has been created with e.g myArray = new
Array("foo",
"bar") or myArray = ["foo", "bar"], x and
myArray[x] will be:
0 - foo
1 - bar
each - function(iterator) {....}
all - function(iterator) {...}
any - function(iterator) {...}
and so on... Actually it will loop over all the Prototype methods added
to the Array object.
I''m not sure whether this is a bug or something I''m doing
wrong..
Regards,
Renaud
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Hey there! Renaud a écrit :> Is there a way to create regular javascript arrays when using > Prototype?Nope. Since the prototype is extended, there''s no way to create an array w/o those. However, you can create an object that acts as an array (a container with properties, that is), and pass it off to functions using for/in loops: var myContainer = { ''0'': ''foo'', ''1'': ''bar'' }; This gets tricky for dynamic addition of properties though (since using a length property in there would make the length property appear in the for/in loop...).> sites but it already uses lots of other pieces of javascript that use > the for (x in myArray)... construction. When using that kind of loopWell, for/in is not exactly intended for array looping. It''s a property iteration mechanism. Codes that use it for array looping are relying on the fact that arrays are not extended in any way, which isn''t very clean, because prototype-extension-based frameworks are gaining major foothold in the web client-side world. So your best bet /in the long run/ would be to avoid such code (if you wrote it, switch to numerical loops; if you didn''t, request a fix from the original coders; if they won''t respond, switch to another lib!).> I''m not sure whether this is a bug or something I''m doing wrong..The for/in code for array iteration does something inadequate, inasmuch as this doesn''t play well with "programming in the large" (in this context, playing nicely with large amounts of external code and possible object extensions). ''HTH. -- Christophe Porteneuve aka TDD tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.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 -~----------~----~----~----~------~----~------~--~---
Agreed. Using "for property in object" with an Array completely forgoes any advantages of even using the Array object. In fact, you might as well just use an Object then. I''ve said it before, and I''ll keep screaming it... don''t use an Array like a hash! Use indexes and push(), splice(), etc... or just don''t use Array. On 11/2/06, Christophe Porteneuve <tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:> > > Hey there! > > Renaud a écrit : > > Is there a way to create regular javascript arrays when using > > Prototype? > > Nope. Since the prototype is extended, there''s no way to create an > array w/o those. However, you can create an object that acts as an > array (a container with properties, that is), and pass it off to > functions using for/in loops: > > var myContainer = { ''0'': ''foo'', ''1'': ''bar'' }; > > This gets tricky for dynamic addition of properties though (since using > a length property in there would make the length property appear in the > for/in loop...). > > > sites but it already uses lots of other pieces of javascript that use > > the for (x in myArray)... construction. When using that kind of loop > > Well, for/in is not exactly intended for array looping. It''s a property > iteration mechanism. Codes that use it for array looping are relying on > the fact that arrays are not extended in any way, which isn''t very > clean, because prototype-extension-based frameworks are gaining major > foothold in the web client-side world. > > So your best bet /in the long run/ would be to avoid such code (if you > wrote it, switch to numerical loops; if you didn''t, request a fix from > the original coders; if they won''t respond, switch to another lib!). > > > I''m not sure whether this is a bug or something I''m doing wrong.. > > The for/in code for array iteration does something inadequate, inasmuch > as this doesn''t play well with "programming in the large" (in this > context, playing nicely with large amounts of external code and possible > object extensions). > > ''HTH. > > -- > Christophe Porteneuve aka TDD > tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org > > > >-- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-920-955-1457 Blog: http://www.someElement.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 -~----------~----~----~----~------~----~------~--~---
Ryan Gahl wrote: [...]> Using "for property in object" with an Array completely forgoes any > advantages of even using the Array object.I think you''ve overstated your case. The fact that for..in is used has no effect on the array itself, how can it *completely* forgo (as in remove the benefit of) an array''s advantages? For example, for..in is used in mathematical operations for sparse arrays - it can be significantly faster (depending on how sparse the array is) than iterating over all the elements using the length property.> In fact, you might as well just > use an Object then. I''ve said it before, and I''ll keep screaming it... don''t > use an Array like a hash! Use indexes and push(), splice(), etc... or just > don''t use Array.A good suggestion, but there are circumstances where using for..in with an array makes sense.> On 11/2/06, Christophe Porteneuve <tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:[...]> > Well, for/in is not exactly intended for array looping. It''s a property > > iteration mechanism. Codes that use it for array looping are relying on > > the fact that arrays are not extended in any way, which isn''t very > > clean, because prototype-extension-based frameworks are gaining major > > foothold in the web client-side world.If you are using multiple libraries, you should have a strong preference for those that don''t modify built-in objects. [...]> > The for/in code for array iteration does something inadequate, inasmuch > > as this doesn''t play well with "programming in the large" (in this > > context, playing nicely with large amounts of external code and possible > > object extensions).I think you have that backwards - libraries that modify built-in objects don''t play well with code that expects those objects to be unadulterated. -- Fred --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hello Fred, Fred a écrit :> A good suggestion, but there are circumstances where using for..in with > an array makes sense.Agreed, but just how border-case are those? The sparse array example you provide is good, but extremely seldom, and architecturally debatable: who wants massive number-crunching in JS?> If you are using multiple libraries, you should have a strong > preference for those that don''t modify built-in objects.This, again, is debatable. Here''s my POV: the only reason prototype extension (as long as it doesn''t break behavior of the prototype''s standard properties) might be a problem is for/in loops, AFAIK. On the other hand, prototype extension is, admittedly, key to leveraging the power of JS. That''s what prototypes are *for*. Most of the really powerful libraries out there rely on prototype extension, which makes for faster, more concise code than vanilla procedural code. And JS 1.7+ follows this trend, going further towards "programming in the large", introducing iterators, array comprehensions, and the like.> I think you have that backwards - libraries that modify built-in > objects don''t play well with code that expects those objects to be > unadulterated.See? POV :-) If built-in objects were not supposed to be extended, they wouldn''t have accessible prototypes. Same goes for DOM objects (but this outside of standard JS scope, it''s more of a browser maker''s choice). Especially in the Rails world, stemming from a language like Ruby where *no class is ever closed*, you can expect people to extend existing objects as they see fit. That could be frowned upon if they broke these object''s inherent behaviors. They generally don''t. However, the whole reason for this discussion is the for/in loop, which is used here mostly as syntactic sugar for array loops, a usage that is definitely *not* its primary purpose. And as we saw, the advantages of such a loop over a vanilla numerical one are few and far between. I hope I''m not feeding a troll here. Were I, let''s avoid feeding it too much further then, this group has been blissfully exempt of those so far. ''best, -- Christophe Porteneuve a.k.a. TDD "[They] did not know it was impossible, so they did it." --Mark Twain Email: tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.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 -~----------~----~----~----~------~----~------~--~---
Christophe Porteneuve wrote:> Hello Fred, > > Fred a écrit :[...]> > If you are using multiple libraries, you should have a strong > > preference for those that don''t modify built-in objects. > > This, again, is debatable.Hence this debate. :-)> Here''s my POV: the only reason prototype > extension (as long as it doesn''t break behavior of the prototype''s > standard properties) might be a problem is for/in loops, AFAIK.Also where two libraries add a property with the same name to the same object''s prototype chain - json.js stomps (quite deliberately) on the toString() method of all built-in objects. The concept of namespaces has been implemented by many libraries to ensure they have a minimal footprint.> On the > other hand, prototype extension is, admittedly, key to leveraging the > power of JS. That''s what prototypes are *for*. Most of the really > powerful libraries out there rely on prototype extension, which makes > for faster, more concise code than vanilla procedural code.The discussion here is not about modifying prototypes in general (if that were a problem the answer is "don''t use a prototype based language") but about libraries (or "frameworks" to be hip) extending the prototypes of built-in objects.> > I think you have that backwards - libraries that modify built-in > > objects don''t play well with code that expects those objects to be > > unadulterated. > > See? POV :-) If built-in objects were not supposed to be extended, > they wouldn''t have accessible prototypes.The issue is using a *library* that extends built-in objects, not extending object prototypes in general. Prototype.js has already been modified (as far as I know) to not extend Object based (I guess) on feedback from users ("users" being developers using Prototype.js). One could argue that JavaScript was intended to be a small, simple language. The fact that there is no mechanism to add non-enumerable properties could be seen as encouragement not to extend built-in objects, and encouragement to provide customised objects within a namespace rather than a global context.> Same goes for DOM objects > (but this outside of standard JS scope, it''s more of a browser maker''s > choice).The results of extending DOM objects is browser-dependent. The ECMAScript Language specification essentially says "host objects can do what they like", which is just as well given the wide variety of host platforms (other than browsers) on which it is implemented. In regard to the W3C''s DOM, its specifications are not necessarily peculiar to javacscript. They are intended to describe interfaces that can be implemented in any language, and should represent a common set of functionality - it should not attempt to be the bleeding edge. [...]> However, the whole reason for this discussion is the for/in loop, which > is used here mostly as syntactic sugar for array loops, a usage that is > definitely *not* its primary purpose.It is a direct consequence of Array being an extension of Object. An alternative view is that Array should have all the properties (either inferred or explit) of Object, in addition to those provided by Array.prototype. -- Fred --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> > It is a direct consequence of Array being an extension of Object. An > alternative view is that Array should have all the properties (either > inferred or explit) of Object, in addition to those provided by > Array.prototype.But if you create an Array, and then "for/in" through it''s "Object properties"... what''s the point of even instantiating an Array? Why not just use an Object if you are not using the collection specific methods and features of the Array object? And if you''ve issues with the sugar, why use it? I''m not saying you necessarily are one of these people, but we don''t really need another guy to come into the prototype/scriptaculous list to tell us why we shouldn''t use prototype/scriptaculous. We already know what the sugar does, it''s sweet and good and we like it. I''ve never had an issue with for/in because i don''t use it with an Array, I use the array functions of the Array object or I use an Object or a custom Hash class when i need an associative array or robust dictionary features. ...but, that''s just me... and my opinion :-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---