> 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: [email protected]
[mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]

Interesting 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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to