Will #in? be in ruby2? (was Re: Finding shared elements between to arrays.)

[PeSSSSaS_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

[PeSSSSaS_Botp]

On 10/9/07, Peña, Botp [email protected] wrote:

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.

[PeSSSSaS_Botp]

From: Devi Web D. [mailto:[email protected]]

> 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

[PeSSSSaS_Botp]

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,

[PeSSSSaS_Botp]

Peña wrote:

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

[PeSSSSaS_Botp]

On 10 Oct 2007, at 14:06, Peña, Botp wrote:

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

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 G.

Bioinformatics Center
Kyoto University

[PeSSSSaS_Botp]

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.

mortee

[PeSSSSaS_Botp]

On 10/10/07, Peña, Botp [email protected] wrote:

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

[PeSSSSaS_Botp]

Hi –

On Wed, 10 Oct 2007, mortee wrote:

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…
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

[PeSSSSaS_Botp]

On 10/10/07, Robert D. [email protected] wrote:

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

[PeSSSSaS_Botp]

From: Alex G.

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):

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

[PeSSSSaS_Botp]

On 10/11/07, Robert K. [email protected] wrote:

situation when there is an instance method in the class and then a
singleton method definition is attempted.

Jim W. 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.

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!

It pays to read the classics!

Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

[PeSSSSaS_Botp]

2007/10/10, mortee [email protected]:

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.

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

[PeSSSSaS_Botp]

On 10/10/07, Robert D. [email protected] wrote:

… but it is not the same , & eliminates duplicates, always forget
about this

Also, #& uses #eql? whereas #include? uses #== .

[PeSSSSaS_Botp]

2007/10/12, George [email protected]:

On 10/10/07, Alex G. [email protected] 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 ?

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

[PeSSSSaS_Botp]

On 10/10/07, Alex G. [email protected] 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 ?