What''s the best way to get the length of a hash? ie. the number of keys? -Daniel --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Daniel Eben Elmore a écrit :> What''s the best way to get the length of a hash? ie. the number of keys?There''s no really fast way, so you can go short or efficient. Short: - with an actual Hash: hash.size() - with a regular object: Object.keys(o).length Efficient: you''ll need to write custom functions, /a la RobG/ ;-): - with an actual Hash: // Post Enumerable mix-in: Hash.prototype.size = function() { var result = 0; for (var key in this) { if (this[key] && this[key] == Hash.prototype[key]) continue; ++result; } return result; }; - with a regular object: Object.getKeyCount = function(o) { var result = 0; for (var key in o) ++resule; return result; }; // Then: Object.getKeyCount(o) ''HTH -- 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 -~----------~----~----~----~------~----~------~--~---
Thank you Christophe, that clears up a lot of confusion over what I read in the docs. Daniel -----Original Message----- From: rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org [mailto:rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org] On Behalf Of Christophe Porteneuve Sent: Monday, July 02, 2007 12:44 PM To: rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Subject: [Rails-spinoffs] Re: Length of a Hash? Daniel Eben Elmore a écrit :> What''s the best way to get the length of a hash? ie. the number of keys?There''s no really fast way, so you can go short or efficient. Short: - with an actual Hash: hash.size() - with a regular object: Object.keys(o).length Efficient: you''ll need to write custom functions, /a la RobG/ ;-): - with an actual Hash: // Post Enumerable mix-in: Hash.prototype.size = function() { var result = 0; for (var key in this) { if (this[key] && this[key] == Hash.prototype[key]) continue; ++result; } return result; }; - with a regular object: Object.getKeyCount = function(o) { var result = 0; for (var key in o) ++resule; return result; }; // Then: Object.getKeyCount(o) ''HTH -- 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 -~----------~----~----~----~------~----~------~--~---
Hi Christophe, I wonder about the real difference of that. Do you have metrics of both implementations to compare convenience? Anyway.. my point is that I''m wondering why Hash don''t answers to size itself with the best (possible at the moment) implementation to query and answer it''s actual size? If your algorithm introduces, let''s say 2% o more better performance, so what Prototype team is waiting to adopt it 1) increasing the semantic power of Hash 2) without injecting complexity 3) preventing people to do hackish things like injecting that algorithm in their programs/pages just to know a size 4) hiding algorithms that tomorrow could be inproved 5) futurely improving them and automagically everybody''s work because they will be prevented to refactor one line of code in their work (should I continue?) ? cheers, Sebastian On 2 jul, 14:43, Christophe Porteneuve <t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:> Daniel Eben Elmore a écrit : > > > What''s the best way to get the length of a hash? ie. the number of keys? > > There''s no really fast way, so you can go short or efficient. Short: > > - with an actual Hash: hash.size() > - with a regular object: Object.keys(o).length > > Efficient: you''ll need to write custom functions, /a la RobG/ ;-): > > - with an actual Hash: > > // Post Enumerable mix-in: > Hash.prototype.size = function() { > var result = 0; > for (var key in this) { > if (this[key] && this[key] == Hash.prototype[key]) continue; > ++result; > } > return result; > }; > > - with a regular object: > > Object.getKeyCount = function(o) { > var result = 0; > for (var key in o) > ++resule; > return result; > }; > // Then: Object.getKeyCount(o) > > ''HTH > > -- > Christophe Porteneuve a.k.a. TDD > "[They] did not know it was impossible, so they did it." --Mark Twain > Email: t...-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 -~----------~----~----~----~------~----~------~--~---
Sebastian Sastre a écrit :> I wonder about the real difference of that. Do you have metrics of > both implementations to compare convenience?I don''t need to. Relying on Hash#_each will create pair objects and invoke an iterator on each turn, which in turn will rely on Enumerable#each thereby working within a try/catch block. Both these aspects guarantee a significantly lower performance to raw looping.> Anyway.. my point is that I''m wondering why Hash don''t answers to > size itself with the best (possible at the moment) implementation to > query and answer it''s actual size?This was deemed unnecessary. Personally, I hardly see why I''d want the size of a Hash, I certainly never needed that. So the default implementation, which is certainly perfectible on a case-by-case basis, is used.> If your algorithm introduces, let''s say 2% o more better > performance, so what Prototype team is waiting to adopt it 1)"YAGNI", my friend. Prototype doesn''t need to clutter itself with addressing minority needs from the world over. We don''t try to be everything to everybody, but to address a reasonable feature set. -- 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?hl=en -~----------~----~----~----~------~----~------~--~---
On 3 jul, 09:48, Christophe Porteneuve <t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:> Sebastian Sastre a écrit : > > > I wonder about the real difference of that. Do you have metrics of > > both implementations to compare convenience? > > I don''t need to. Relying on Hash#_each will create pair objects and > invoke an iterator on each turn, which in turn will rely on > Enumerable#each thereby working within a try/catch block. Both these > aspects guarantee a significantly lower performance to raw looping. > > > Anyway.. my point is that I''m wondering why Hash don''t answers to > > size itself with the best (possible at the moment) implementation to > > query and answer it''s actual size? > > This was deemed unnecessary. Personally, I hardly see why I''d want the > size of a Hash, I certainly never needed that. So the default > implementation, which is certainly perfectible on a case-by-case basis, > is used. > > > If your algorithm introduces, let''s say 2% o more better > > performance, so what Prototype team is waiting to adopt it 1) > > "YAGNI", my friend. Prototype doesn''t need to clutter itself with > addressing minority needs from the world over. We don''t try to be > everything to everybody, but to address a reasonable feature set. > > -- > Christophe Porteneuve aka TDD > t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.orgInteresting way to see things. On the other hand you have that 1) the fact taht Daniel already needed it for whatever reason he has and 2) the most basic things that you do with lists are: 1) add a thing 2) remove a thing 3) locate a thing 4) see if a thing is included in it 5) query its size (probably useful to locate and see if something is included among other uses) Several others can be implemented using them like removing all or returning the last one. To be honest I had to note and tell you that I''ve also didn''t need (yet) the size in hash, but I bet that will do in the long run (that in TI could be 6-12 months). I''m asking more to understand Prototype''s people criteria to adopt features (thing that you kindly answered me by the way). And I agree in the focus of features and the lazy criteria of waiting that a critical mass ask for it for economical reasons (even in a open community I consider this important). Or by doing it yourself that is probably my approach. If I need enough it I would like to implement Dictionary using "behind the scenes" a Hash with the exposed features in a simple yet powerful semantic with the plus of hiding the unnecessary complexity. In sum I take this chance to express that diverging from that is an anti-minimalistic attitude to me. cheers, Sebastian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> Personally, I hardly see why I''d want the size of > a Hash, I certainly never needed that.Really? I could use a multi-dim array to store the key/value pairs, but that just seems messy. Not sure if that''s what everyone else is doing. Anyways, thanks for the help. -Daniel -----Original Message----- From: rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org [mailto:rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org] On Behalf Of Sebastian Sastre Sent: Tuesday, July 03, 2007 9:30 AM To: Ruby on Rails: Spinoffs Subject: [Rails-spinoffs] Re: Length of a Hash? On 3 jul, 09:48, Christophe Porteneuve <t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:> Sebastian Sastre a écrit : > > > I wonder about the real difference of that. Do you have metrics of > > both implementations to compare convenience? > > I don''t need to. Relying on Hash#_each will create pair objects and > invoke an iterator on each turn, which in turn will rely on > Enumerable#each thereby working within a try/catch block. Both these > aspects guarantee a significantly lower performance to raw looping. > > > Anyway.. my point is that I''m wondering why Hash don''t answers to > > size itself with the best (possible at the moment) implementation to > > query and answer it''s actual size? > > This was deemed unnecessary. Personally, I hardly see why I''d want the > size of a Hash, I certainly never needed that. So the default > implementation, which is certainly perfectible on a case-by-case basis, > is used. > > > If your algorithm introduces, let''s say 2% o more better > > performance, so what Prototype team is waiting to adopt it 1) > > "YAGNI", my friend. Prototype doesn''t need to clutter itself with > addressing minority needs from the world over. We don''t try to be > everything to everybody, but to address a reasonable feature set. > > -- > Christophe Porteneuve aka TDD > t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.orgInteresting way to see things. On the other hand you have that 1) the fact taht Daniel already needed it for whatever reason he has and 2) the most basic things that you do with lists are: 1) add a thing 2) remove a thing 3) locate a thing 4) see if a thing is included in it 5) query its size (probably useful to locate and see if something is included among other uses) Several others can be implemented using them like removing all or returning the last one. To be honest I had to note and tell you that I''ve also didn''t need (yet) the size in hash, but I bet that will do in the long run (that in TI could be 6-12 months). I''m asking more to understand Prototype''s people criteria to adopt features (thing that you kindly answered me by the way). And I agree in the focus of features and the lazy criteria of waiting that a critical mass ask for it for economical reasons (even in a open community I consider this important). Or by doing it yourself that is probably my approach. If I need enough it I would like to implement Dictionary using "behind the scenes" a Hash with the exposed features in a simple yet powerful semantic with the plus of hiding the unnecessary complexity. In sum I take this chance to express that diverging from that is an anti-minimalistic attitude to me. cheers, Sebastian --~--~---------~--~----~------------~-------~--~----~ 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, Sebastian Sastre a écrit :> the most basic things that you do with lists are:With *lists*, exactly. Not hashes / associative arrays.> Several others can be implemented using them like removing all or > returning the last one.Hashes / associative arrays have no intrinsic order, so the "last" one is not a valid notion.> criteria of waiting that a critical mass ask for it for economical > reasons (even in a open community I consider this important). Or byIt''s not about economics, it''s about feature bloat... Not quite the same thing. -- 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?hl=en -~----------~----~----~----~------~----~------~--~---
Hi, some replies below.. On 3 jul, 11:50, Christophe Porteneuve <t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:> Hey, > > Sebastian Sastre a écrit : > > > the most basic things that you do with lists are: > > With *lists*, exactly. Not hashes / associative arrays. > > > Several others can be implemented using them like removing all or > > returning the last one. > > Hashes / associative arrays have no intrinsic order, so the "last" one > is not a valid notion. >Yes, you''re right. I should put a protocol for associative lists (like dictionaries) but my general point remains.> > criteria of waiting that a critical mass ask for it for economical > > reasons (even in a open community I consider this important). Or by > > It''s not about economics, it''s about feature bloat...Well, if computers came back to have 16K and networks 2 kbps we all will certainly justify a lot of optimizations. But if we are programing for the near future I think we should think big not small so using stinginess of features as a default criteria for essential features just does not make me feel comfortable (nor yesterday not todays!).> Not quite the > same thing. >About economics, you''ll had to admit that indirectly it touches economics in a lot of ways (broadband, success in user experience, operative costs of developers, etc). So maybe is it was not though with economic in mind explicitly but I''m pretty sure it does intuitively.> -- > Christophe Porteneuve aka TDD > t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.orgcheers ! Sebastian PS: if the essence of Hash is to be an array (list or unordered collection) of associations between objects I wonder why that was not prioritized in it''s naming time. For some reason (that I think is only relevant to evade to use it again), instead was prioritized in the name, the accidental anecdote which says that today''s *associative list* are implemented using the association''s hashes (that are essentially checksums) and crystallize that essence divergent idea by "baptizing" it that way. IMHO that mislead of priority at naming time is forcing you to explain and/or document that detail over and over because a divergent suggestion and wasting use of words that already exist to describe that essence. Confusivity by default. Strange. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
One of the things to be aware of: The hottest tech gadget on the market, the iPhone, has a pitiful connection speed, and by all benchmarks is incredibly slow when compared with a desktop (even an old one). For the company I''m building product for now, we have a significant number of customers who still use dial-up, which isn''t well supported. This summer we''ll be going back and reworking portions of our application to better work with dial-up. With this in mind, library optimizations, including concern for library size, are critically important. If there is a feature you need, you''re always welcome to hack/modify/ override parts of the Prototype library. I do. TAG On Jul 3, 2007, at 11:22 AM, Sebastian Sastre wrote:> On 3 jul, 11:50, Christophe Porteneuve <t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote: >> It''s not about economics, it''s about feature bloat... > Well, if computers came back to have 16K and networks 2 kbps we all > will certainly justify a lot of optimizations. But if we are > programing for the near future I think we should think big not small > so using stinginess of features as a default criteria for essential > features just does not make me feel comfortable (nor yesterday not > todays!).--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I agree with Christophe and Tom, retrieving the size of a hash is an edge case in my book. I think the data type might be misused in the implementation, a hash is intended to be a collection of hashed values that are quickly accessible via a key. If you need the number of values in the hash, keep track of this variable at the point where you''re adding the value to hash so its available without iteration calculations. On the other side of the argument, if you don''t need the accessibility that the hash allows via key values you may just want to use an Enumerable/Array. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---