Eric wrote:
a3 = a1.select { |e| a2.include?(e) }
compare:
a3 = a1.select { |e| e.in? a2}
the latter is more straightforward. the former expression rocks my brain from left to right.
Can we see light for #in? in ruby2? (just asking since december is near 
and i do not see it in mauricio's eigenclass site either)
kind regards -botp
I really don't like that proposal. It's not a property of e that it is in
a2, its a property of a2 that it contains e.
On 10/9/07, Peña, Botp <botp@delmonte-phil.com> wrote:
compare:
a3 = a1.select { |e| e.in? a2}
-------------------------------------------
Daniel Brumbaugh Keeney
Devi Web Development
Devi.WebMaster@gMail.com
-------------------------------------------
Quoth Peña, Botp:
Eric wrote:
> a3 = a1.select { |e| a2.include?(e) }
>compare:
a3 = a1.select { |e| e.in? a2}the latter is more straightforward. the former expression rocks my brain
from left to right.
Can we see light for #in? in ruby2? (just asking since december is near
and i do not see it in mauricio's eigenclass site either)
kind regards -botp
Array#include?
arr = [:sym, 'str'] # => [:sym, 'str']
arr.include? :sym # => true
HTH,
--
Konrad Meyer <konrad@tylerc.org> http://konrad.sobertillnoon.com/
As most other posters I am opposed to #in? (really how can it be the
responsibility of an arbitrary object to implement test for
containment) , but I would rather compare
a3 = a1.select{ |e| e.in? a2}
to
a3 = a1 & a2
Cheers
Robert
On 10/10/07, Peña, Botp <botp@delmonte-phil.com> wrote:
Eric wrote:
> a3 = a1.select { |e| a2.include?(e) }
>compare:
a3 = a1.select { |e| e.in? a2}the latter is more straightforward. the former expression rocks my brain from left to right.
Can we see light for #in? in ruby2? (just asking since december is near
--
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/
# > compare:
# > a3 = a1.select { |e| e.in? a2}
# >
# I really don't like that proposal. It's not a property of e
# that it is in a2, its a property of a2 that it contains e.
pls enlighten my poor brain 
i just want to ask if e is in a2. same way like i want to ask eg if e==2 ... in fact, i find #in? so generic...
or maybe you want a keyword only like msbasic's
e in a2
?
kind regards -botp
From: Devi Web Development [mailto:devi.webmaster@gmail.com]
<snip>
containment) , but I would rather compare
a3 = a1.select{ |e| e.in? a2}
to
a3 = a1 & a2
... but it is not the same 
, & eliminates duplicates, always forget
about this
Sorry
Robert
On 10/10/07, Robert Dober <robert.dober@gmail.com> wrote:
--
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/
Peña wrote:
From: Devi Web Development [mailto:devi.webmaster@gmail.com]
# > compare:
# > a3 = a1.select { |e| e.in? a2}
# >
# I really don't like that proposal. It's not a property of e
# that it is in a2, its a property of a2 that it contains e.pls enlighten my poor brain
i just want to ask if e is in a2. same way like i want to ask eg if e==2 ... in fact, i find #in? so generic...
or maybe you want a keyword only like msbasic's
e in a2
?
kind regards -botp
Why don't you just define #in? in Object yourself, and then you can use
it anywhere in your code. That's something I really like about Ruby: if
I'm missing something from a core or library class, I can just drop it
in for my own use.
mortee
If I understand you correctly the :in? method would have to be defined in Object (so that all Objects could be tested). So something like:
irb(main):001:0> class Object
irb(main):002:1> def in?(enum)
irb(main):003:2> enum.include?(self)
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> 1.in? [1,2,3]
=> true
irb(main):007:0> 4.in? [1,2,3]
=> false
Daniel's point (I think) is that this pollutes the top level Object with a property which for many (most?) Objects is never relevant. If you never put it an Object into a collection then the idea of being 'in' something makes no sense.
On the other hand it is always an intrinsic part of an Enumerable implementing class (by definition a collection of Objects) that you may often need to know whether it 'includes' a specified object.
I'm not sure why the includes construct rocks your brain though. Both read very logically to me (as a native English speaker admittedly):
a3 = a1.select { |e| a2.include?(e) }
reads as: 'select' from a1 those e where a2 'includes' e.
a3 = a1.select { |e| e.in? a2}
reads as: 'select' from a1 those e where e is 'in' a2.
That said I always write this as:
a3 = a1 & a2
Alex Gutteridge
Bioinformatics Center
Kyoto University
On 10 Oct 2007, at 14:06, Peña, Botp wrote:
From: Devi Web Development [mailto:devi.webmaster@gmail.com]
# > compare:
# > a3 = a1.select { |e| e.in? a2}
# >
# I really don't like that proposal. It's not a property of e
# that it is in a2, its a property of a2 that it contains e.pls enlighten my poor brain
i just want to ask if e is in a2. same way like i want to ask eg if e==2 ... in fact, i find #in? so generic...
or maybe you want a keyword only like msbasic's
e in a2
?
kind regards -botp
Also, #& uses #eql? whereas #include? uses #== .
On 10/10/07, Robert Dober <robert.dober@gmail.com> wrote:
On 10/10/07, Robert Dober <robert.dober@gmail.com> wrote:
<snip>
> containment) , but I would rather compare
>
> a3 = a1.select{ |e| e.in? a2}
>
> to
>
> a3 = a1 & a2
>
... but it is not the same
about this
Hi --
On Wed, 10 Oct 2007, mortee wrote:
Peña wrote:
From: Devi Web Development [mailto:devi.webmaster@gmail.com]
# > compare:
# > a3 = a1.select { |e| e.in? a2}
# >
# I really don't like that proposal. It's not a property of e
# that it is in a2, its a property of a2 that it contains e.pls enlighten my poor brain
i just want to ask if e is in a2. same way like i want to ask eg if e==2 ... in fact, i find #in? so generic...
or maybe you want a keyword only like msbasic's
e in a2
?
kind regards -botp
Why don't you just define #in? in Object yourself, and then you can use
it anywhere in your code. That's something I really like about Ruby: if
I'm missing something from a core or library class, I can just drop it
in for my own use.
It's not risk-free, though, since if two people define a given method
differently, one of them will get trampled on.
David
--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!
# Daniel's point (I think) is that this pollutes the top
# level Object with a property which for many (most?)
# Objects is never relevant. If
arggh, i wish we could measure that "pollution". (sometimes, i even includes Trans's facets gem of extensions 
My addition of it is not about polluting, it's about me expressing my thoughts well in a program. I thought in? would include just a very small helpful code.
# you never put it an Object into a collection then
# the idea of being 'in' something makes no sense.
well i thought that all objects in ruby can be put into a container, so i reckon #in? (like #include?) would be very handy too. I use it many times.
# On the other hand it is always an intrinsic part
# of an Enumerable implementing class (by definition
# a collection of Objects) that you may often need to
# know whether it 'includes' a specified object.
no problem there.
# I'm not sure why the includes construct rocks your brain
# though. Both read very logically to me (as a native
# English speaker admittedly):
From: Alex Gutteridge
#
# a3 = a1.select { |e| a2.include?(e) }
#
# reads as: 'select' from a1 those e where a2 'includes' e.
#
# a3 = a1.select { |e| e.in? a2}
#
# reads as: 'select' from a1 those e where e is 'in' a2.
i'm reading it again, and i still find the second one much better to read, it's straightforward and you can read it fast.
try reading it like in math or in symbolic logic,
{|e| e.in? a}
read: "e such that e is in a"
whereas
{|e| a.in? e}
read: "e such that a includes e"
suddenly, my point of (object) reference changes from e to a and from left to right. which is kind of weird to me assumming I were to right it in a technical report.
I would use include? and in? like the ff,
{|a| a.include? e}
{|e| e.in? a}
note the similarity and difference. clear reading left to right. Clearly, if there's a place for include?, there is too for in?.
# That said I always write this as:
# a3 = a1 & a2
that was just a simple example (and besides, i'm not even sure they are the same) to show difference bw include? and in?.
kind regards -botp
Just playing devil's advocate, but could the same thing not be said
for Object#hash ?
On 10/10/07, Alex Gutteridge <alexg@kuicr.kyoto-u.ac.jp> wrote:
On 10 Oct 2007, at 14:06, Peña, Botp wrote:
Daniel's point (I think) is that this pollutes the top level Object
with a property which for many (most?) Objects is never relevant. If
you never put it an Object into a collection then the idea of being
'in' something makes no sense.
David A. Black wrote:
Hi --
Why don't you just define #in? in Object yourself, and then you can use
it anywhere in your code. That's something I really like about Ruby: if
I'm missing something from a core or library class, I can just drop it
in for my own use.It's not risk-free, though, since if two people define a given method
differently, one of them will get trampled on.
Yeah, that's what the other thread "Open-Closed..." is about in part:
method name collisions whithin a module/class coming from different sources.
I think that this problem should be solved somehow instead of avoiding
the power of ability to extend arbitrary classes. I'm absolutely aware
of the issue though.
mortee
On Wed, 10 Oct 2007, mortee wrote:
Hehe, very true. I think the judgment whether to put a method in
Object should rather be whether it is sufficient general - which makes
it harder to put down #in?.
Me personally I am rather unbiased on this one apart from that I do
not find the current state of affairs difficult to understand or use.
My 0.02EUR
Kind regards
robert
2007/10/12, George <george.ogata@gmail.com>:
On 10/10/07, Alex Gutteridge <alexg@kuicr.kyoto-u.ac.jp> wrote:
> On 10 Oct 2007, at 14:06, Peña, Botp wrote:
> Daniel's point (I think) is that this pollutes the top level Object
> with a property which for many (most?) Objects is never relevant. If
> you never put it an Object into a collection then the idea of being
> 'in' something makes no sense.Just playing devil's advocate, but could the same thing not be said
for Object#hash ?
While reading this thread another possible solution came to my mind:
what about an operator like "def_once" or "def!" which will raise an
exception if the method is defined for that class already? Of course,
we could cook our own using define_method but there are some
restrictions so it's not exactly equivalent to def.
Semantics would have to be carefully chosen. At the moment it seems
that "def_once" should raise only if a) the instance's class has an
instance method of the same name already or b) there is a singleton
method of the same name. However, I am not sure how to deal with the
situation when there is an instance method in the class and then a
singleton method definition is attempted.
What do you guys think? This would at least make sure that you
immediately notice if a method is defined twice and it seems to easier
integrate with the language than selector namespaces.
Kind regards
robert
2007/10/10, mortee <mortee.lists@kavemalna.hu>:
David A. Black wrote:
> Hi --
>
> On Wed, 10 Oct 2007, mortee wrote:
>> Why don't you just define #in? in Object yourself, and then you can use
>> it anywhere in your code. That's something I really like about Ruby: if
>> I'm missing something from a core or library class, I can just drop it
>> in for my own use.
>
> It's not risk-free, though, since if two people define a given method
> differently, one of them will get trampled on.Yeah, that's what the other thread "Open-Closed..." is about in part:
method name collisions whithin a module/class coming from different sources.I think that this problem should be solved somehow instead of avoiding
the power of ability to extend arbitrary classes. I'm absolutely aware
of the issue though.
Jim Weirich uses something like this in rake. He defines a method
which takes a block containing a method definition
class Module
# Check for an existing method in the current class before extending. IF
# the method already exists, then a warning is printed and the extension is
# not added. Otherwise the block is yielded and any definitions in the
# block will take effect.
On 10/11/07, Robert Klemme <shortcutter@googlemail.com> wrote:
While reading this thread another possible solution came to my mind:
what about an operator like "def_once" or "def!" which will raise an
exception if the method is defined for that class already? Of course,
we could cook our own using define_method but there are some
restrictions so it's not exactly equivalent to def.Semantics would have to be carefully chosen. At the moment it seems
that "def_once" should raise only if a) the instance's class has an
instance method of the same name already or b) there is a singleton
method of the same name. However, I am not sure how to deal with the
situation when there is an instance method in the class and then a
singleton method definition is attempted.
#
# Usage:
#
# class String
# rake_extension("xyz") do
# def xyz
# ...
# end
# end
# end
#
def rake_extension(method)
if instance_methods.include?(method)
$stderr.puts "WARNING: Possible conflict with Rake extension:
#{self}##{method} already exists"
else
yield
end
end
end
Note that it produces a warning rather than an exception.
Also I guess he figured that Module#rake_extension wouldn't already exist! <G>
It pays to read the classics!
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/