Good catch. Enough reason to have something for it, I think. I may add a
general method to my libs:
class Array
def compact_on(n=nil)
if n
delete(n)
else
compact
end
self
end
end
Better name? Or better solution?
T.
···
On Thursday 09 December 2004 02:04 pm, David A. Black wrote:
Hi --
On Fri, 10 Dec 2004, trans. (T. Onoma) wrote:
> On Thursday 09 December 2004 12:29 pm, Ibraheem Umaru-Mohammed wrote:
> > ++ trans. (T. Onoma) [ruby-talk] [10/12/04 00:43 +0900]:
> > > That reminds me, do we have simple way to delete all empty strings
> > > from an array, like compact is for nil?
> >
> > what's wrong with using Array#delete ?
> >
> > --ibz.
>
> Right. I was thinking #delete only removed the first match it came to.
> But no, it does remove them all. So simple enough. Thanks.
>
> BTW, I mis-tested Florian's example so disregard my last post on the
> subject -- I see the point now.
Small caveat: remember that Array#delete returns the thing deleted,
not the array, so you can't chain it as you would #compact.
It doesn't currently take a parameter, so allow it to take one. FWIW
I think Array#delete should be deprecated, and Array#compact extended
in this fashion. I don't see a good rationale for the return value of
Array#delete, and when a method is called #delete there is always
confusion about whether it's destructive.
Ruby spoils us so much that when you have to look something up in the
docs a few times you feel cheated
Gavin
···
On Friday, December 10, 2004, 7:24:42 AM, trans. wrote:
> Small caveat: remember that Array#delete returns the thing deleted,
> not the array, so you can't chain it as you would #compact.
Good catch. Enough reason to have something for it, I think. I may add a
general method to my libs:
class Array
def compact_on(n=nil)
if n
delete(n)
else
compact
end
self
end
end
Except that takes a block. Hmm, could change reject to also accept a
parameter. Of course we could have compact take a parameter too. Which of the
three is the best way to go?
T.
···
On Thursday 09 December 2004 04:39 pm, Ibraheem Umaru-Mohammed wrote:
+++ trans. (T. Onoma) [ruby-talk] [10/12/04 05:24 +0900]:
> class Array
> def compact_on(n=nil)
> if n
> delete(n)
> else
> compact
> end
> self
> end
> end
>
> Better name? Or better solution?
It doesn't currently take a parameter, so allow it to take one. FWIW
I think Array#delete should be deprecated, and Array#compact extended
in this fashion. I don't see a good rationale for the return value of
Array#delete, and when a method is called #delete there is always
confusion about whether it's destructive.
Fair assessment. I think I'll go this route then. (Although I'll leave #delete
defined, and just generally forget it's even there
Ruby spoils us so much that when you have to look something up in the
docs a few times you feel cheated
LOL. Too true.
Thanks,
T.
···
On Thursday 09 December 2004 04:43 pm, Gavin Sinclair wrote:
It doesn't currently take a parameter, so allow it to take one. FWIW
I think Array#delete should be deprecated, and Array#compact extended
in this fashion. I don't see a good rationale for the return value of
Array#delete, and when a method is called #delete there is always
confusion about whether it's destructive.
Ruby spoils us so much that when you have to look something up in the
docs a few times you feel cheated
[...]
I agree. Something doesn't seem right with Array#delete. When I first
encountered it, I expected only the first object to be removed, not _all_ of
them. And because the deletion was greedy, I thought they'd be an easy way to
specify just how many of those objects you wanted removed. There didn't seem
to be, so I submitted RCR285, along with some suggestions for
Array#delete_at.
I also expected Array#delete to give back a new array with the deleted
objects removed, as my instincts led me to believe there'd be an
Array#delete!. But again, no.
I don't however, agree that Array#delete should be deprecated, simply because
I believe a new ruby programmer is more likely to expect a 'delete' rather
than a 'compact' to do what they want to do. Although that's probably not
reason enough, I suspect they'd check for 'remove' or 'delete' before they
came across 'compact'
Small caveat: remember that Array#delete returns the thing
deleted, not the array, so you can't chain it as you would #compact.
Good catch. Enough reason to have something for it, I think. I
may add a general method to my libs:
[...]
Better name? Or better solution?
Array#compact
It doesn't currently take a parameter, so allow it to take one.
FWIW I think Array#delete should be deprecated, and Array#compact
extended in this fashion. I don't see a good rationale for the
return value of Array#delete, and when a method is called #delete
there is always confusion about whether it's destructive.
a = %w(a b c d a b c d a b c d)
if (a.delete("a"))
...
else
...
end
if (a.delete("z"))
...
else
...
end
-austin
···
On Fri, 10 Dec 2004 06:43:09 +0900, Gavin Sinclair <gsinclair@soyabean.com.au> wrote:
On Friday, December 10, 2004, 7:24:42 AM, trans. wrote:
> Small caveat: remember that Array#delete returns the thing deleted,
> not the array, so you can't chain it as you would #compact.
Good catch. Enough reason to have something for it, I think. I may add a
general method to my libs:
class Array
def compact_on(n=nil)
if n
delete(n)
else
compact
end
self
end
end
Better name? Or better solution?
Array#compact
It doesn't currently take a parameter, so allow it to take one. FWIW
I think Array#delete should be deprecated, and Array#compact extended
in this fashion. I don't see a good rationale for the return value of
Array#delete, and when a method is called #delete there is always
confusion about whether it's destructive.
I would just as soon have things remain as they are (with the possible
exception of making String#delete destructive; I think it's the only
one that isn't). But if Matz chooses to revisit this area, I would
not want to see "compact" become a general-purpose method for removing
elements. [1,2,3,4].compact(3) just doesn't communicate anything
along the lines of [1,2,4].
David
···
On Fri, 10 Dec 2004, Gavin Sinclair wrote:
On Friday, December 10, 2004, 7:24:42 AM, trans. wrote:
I would just as soon have things remain as they are (with the possible
exception of making String#delete destructive; I think it's the only
one that isn't). But if Matz chooses to revisit this area, I would
not want to see "compact" become a general-purpose method for removing
elements. [1,2,3,4].compact(3) just doesn't communicate anything
along the lines of [1,2,4].
I wouldn't say it doesn't communicate anything at all. Compact does make one
think it will be getting smaller. But I take you point, yet isn't it kind of
silly to have two methods such that one of them is just a very limited case
of the other?
So I now find myself wondering how to delete just the first occurring element.
I suppose it's:
a = [1,2,2,3,3,2]
a.delete_at(a.index(2))
A #delete and #delete_all would seem more appropriate. Nontheless, as you
pointed out, its not quite the same as compact because of the return value.
So if not compact then we need a new method, I guess, #remove. But like I
said kind of a waste of namespace.
T.
···
On Thursday 09 December 2004 08:17 pm, David A. Black wrote:
> I would just as soon have things remain as they are (with the possible
> exception of making String#delete destructive; I think it's the only
> one that isn't). But if Matz chooses to revisit this area, I would
> not want to see "compact" become a general-purpose method for removing
> elements. [1,2,3,4].compact(3) just doesn't communicate anything
> along the lines of [1,2,4].
>
I wouldn't say it doesn't communicate anything at all. Compact does make one
think it will be getting smaller. But I take you point, yet isn't it kind of
silly to have two methods such that one of them is just a very limited case
of the other?
I don't think that's all there is to it. The presence of unwanted
nils in arrays is very common, because arrays serve as the receptacle
for operations like map and scan. So having a method dedicated to
that doesn't seem silly to me at all, and it gets used a lot. There's
no iron-clad, slam-dunk necessity for it, I guess, but I personally
think it's a good illustration of the kind of balance (as opposed to
symmetry, which is a different thing) that Matz is so good at
crafting.
David
···
On Fri, 10 Dec 2004, trans. (T. Onoma) wrote:
On Thursday 09 December 2004 08:17 pm, David A. Black wrote:
