> Actually the code $H(originalHash.reject(...)) doesn't return the
> correct value.

Ah, sorry 'bout that, should have tried it.  Clearly I don't create
hashes from arrays very often... ;-)

-- T.J.

On Feb 4, 8:49 pm, Brad <bradavo...@gmail.com> wrote:
> Actually the code $H(originalHash.reject(...)) doesn't return the
> correct value. Example:
> var originalHash = $H({'a':1,'b':2,'c':3,'d':4});
> var newArray = originalHash.filter(function(i) { return i.value %
> 2; })
> => $H(newArray) doesn't have the keys 'a' and 'c'.
>
> You have to call:
> newArray.inject($H(),function(h,i){
>         h.set(i[0],i[1])
>         return h
>
> })
>
> I wasn't suggesting fixing it in a v1.x release, as APIs shouldn't be
> changed in minor releases. Though it is definitely something to keep
> in mind for Prototype v2.0.
>
> On Feb 3, 10:20 pm, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
>
> > Hi Brad,
>
> > > The contract states that Enumerable#reject "Returns all the elements
> > > for which the iterator returned false".
>
> > Here's the opening line of the Enumerable#reject docs:
>
> >     reject(iterator[, context]) -> Array
>
> > Similarly, findAll (the one we started with, via its alias filter):
>
> >     findAll(iterator[, context]) -> Array
>
> > That's not an assumption, that's a documented return value.  Changing
> > these to return a Hash if the original is a Hash breaks the contract
> > and breaks compatibility with previous releases.  Whereas getting the
> > result you want is trivial:
>
> >     result = $H(originalHash.reject(...));
>
> > > It's entirely intuitive that...
>
> > I'm not talking intuitive vs. non-intuitive (it's far too subjective),
> > I'm talking the current documented (and implemented!) behavior.
> > Remember that Enumerable is a contract, and code dealing with an
> > Enumerable may not happen to know that it's dealing with a Hashy kind
> > of Enumerable. :-)
>
> > I do agree -- not that it matters! ;-) -- that for (say) 2.0, an
> > argument can be made for changing Enumerable to say that for these
> > kinds of methods, it returns an Enumerable (not an Array), and that
> > concrete classes should (where appropriate) return the same type as
> > the original.  But (due respect to kangax) to me that's not a bug,
> > that's a request for API enhancement, and not the kind of thing to do
> > in a dot release or by making Hash a special case.
>
> > FWIW,
> > --
> > T.J. Crowder
> > tj / crowder software / com
> > Independent Software Engineer, consulting services available
>
> > On Feb 3, 10:20 pm, Brad <bradavo...@gmail.com> wrote:
>
> > > The contract states that Enumerable#reject "Returns all the elements
> > > for which the iterator returned false". It's entirely intuitive that
> > > it will return the same data type as the object it was called on.
> > > Otherwise Hash#reject() is practically useless.
>
> > > The only part of the documentation that is wrong is the assumption
> > > that it will always return an Array. Perhaps that was an oversight
> > > when Hash was left out as a subclass of Enumerable in the
> > > documentation.
>
> > > Ruby fixed their documentation:
> > > Hash#reject:http://www.ruby-doc.org/core/classes/Hash.html#M002901
> > > Enumerable#reject:http://www.ruby-doc.org/core/classes/Enumerable.html#M003157
>
> > > On Feb 3, 1:56 pm, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
>
> > > > Kangax,
>
> > > > > Didn't we establish that this is a bug? ; )
>
> > > > Not as far as I'm concerned it isn't.  It returns what its documented
> > > > contract says it returns.  The only error IMHO is in the
> > > > interpretation that it would do something other than what the
> > > > documentation says it will do.  You're not suggesting it should break
> > > > the Enumerable contract, are you?
>
> > > > -- T.J. ;-)
>
> > > > On Feb 3, 7:03 pm, kangax <kan...@gmail.com> wrote:
>
> > > > > On Feb 3, 1:54 pm, Brad <bradavo...@gmail.com> wrote:
>
> > > > > > TJ, thanks for correcting the docs. I hadn't noticed that error
> > > > > > either.
>
> > > > > > Are you suggesting that there no intersection of Prototype and Ruby
> > > > > > communities? I only know of Prototype because of Ruby on Rails.
>
> > > > > > Let's take Hash#reject() as an example. Let's say I'm moving server-
> > > > > > side Ruby code to my Prototype-enhanced client-side.
>
> > > > > > Ruby code:
> > > > > > { "a" => 100, "b" => 200, "c" => 300 }.reject {|key, value| key ==
> > > > > > "b" }
> > > > > > => {"a"=>100, "c"=>300}
>
> > > > > > Translated to Javascript:
> > > > > > $H({ "a": 100, "b": 200, "c": 300 }).reject(function(i) { return 
> > > > > > i.key
> > > > > > == "b" })
> > > > > > => [["a", 100], ["c", 300]]
>
> > > > > > Prototype returns an array? What good is an array if I started with 
> > > > > > a
> > > > > > hash? It is intuitive that a reject() method returns a subset of the
> > > > > > original data structure and not convert it to an entirely different
> > > > > > one.
>
> > > > > Didn't we establish that this is a bug? ; )
>
> > > > > --
> > > > > kangax
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to