On Feb 4, 1:20 am, "T.J. Crowder" wrote:
[...]
> 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 i
> 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 wrote:
> Actually the code $H(originalHash.reject(...)) doesn't return t
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(
On Feb 3, 2:18 pm, "T.J. Crowder" wrote:
> Hi,
>
> > Maybe filter should be an alias of findall for arrays, but shouldn't
> > it really return a hash for hashes?
>
> FWIW (and it ain't much, I'm not a decision maker on Prototype stuff),
> in my opinion it would be an _extremely_ bad idea for Ha
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):
fin
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 wr
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
> Perhaps this is a plea better left for the Prototype-core list.
Like I said, I'm not a decision maker here. But breaking contracts is
pretty well established as a Bad Idea.
-- T.J. ;-)
On Feb 3, 6:54 pm, Brad wrote:
> TJ, thanks for correcting the docs. I hadn't noticed that error
> either.
On Feb 3, 1:54 pm, Brad 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 sa
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 Pr
2009/2/3 T.J. Crowder :
>
> Hi,
>
>> Maybe filter should be an alias of findall for arrays, but shouldn't
>> it really return a hash for hashes?
>
> FWIW (and it ain't much, I'm not a decision maker on Prototype stuff),
> in my opinion it would be an _extremely_ bad idea for Hash to break
> the co
Hi,
> Maybe filter should be an alias of findall for arrays, but shouldn't
> it really return a hash for hashes?
FWIW (and it ain't much, I'm not a decision maker on Prototype stuff),
in my opinion it would be an _extremely_ bad idea for Hash to break
the contract documented for Enumerable.
> .
Maybe filter should be an alias of findall for arrays, but shouldn't
it really return a hash for hashes? Especially if thats its behavior
in ruby, which Prototype is supposed to be modeled after.
On Feb 3, 4:59 am, "T.J. Crowder" wrote:
> Hi Brad,
>
> Sorry, I missed that Hash inherits from Enum
Hi Brad,
Sorry, I missed that Hash inherits from Enumerable (and I've filed a
doc bug on it[1] and will fix it -- the doc page for Hash doesn't
mention Enumerable).
So I think that's your answer: Hash#filter is an alias for
Enumerable#findAll[2], which is documented as returning an array, not
a
It does. Hash still inherits from Enumerable, hence the usage of
Hash#findAll().
- Brad
On Feb 2, 1:34 am, ColinFine wrote:
> On Jan 31, 11:11 pm, Brad wrote:
>
> > Yup, found it -http://dev.rubyonrails.org/ticket/3592
>
> > It is indeed a bug in Prototype that hasn't been addressed.
>
> > - B
On Jan 31, 11:11 pm, Brad wrote:
> Yup, found it -http://dev.rubyonrails.org/ticket/3592
>
> It is indeed a bug in Prototype that hasn't been addressed.
>
> - Brad
But it seems to me that it's gone away, because Hash no longer mixes
in Enumerable, does it?
Colin
--~--~-~--~~-
Yup, found it - http://dev.rubyonrails.org/ticket/3592
It is indeed a bug in Prototype that hasn't been addressed.
- Brad
On Jan 30, 6:23 pm, kangax wrote:
> On Jan 30, 6:05 pm, Brad wrote:
>
> > Why does Hash#filter return an Array instead of a Hash? It isn't
> > really a filter if it's retu
On Jan 30, 6:05 pm, Brad wrote:
> Why does Hash#filter return an Array instead of a Hash? It isn't
> really a filter if it's returning another data type.
>
> Instead of
> $H({'a':1,'b':2,'c':3,'d':4}).filter(function(i) { return i.value %
> 2; })
> that returns,
> [["a", 1], ["c",
Hi,
Prototype's Hash object doesn't have a filter method, according to the
docs.[1] The only filter method I can find in Prototype is an
Enumerable alias for findAll().
[1] http://prototypejs.org/api/hash
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting serv
19 matches
Mail list logo
