difference?

[Gábor SEBESTYÉN]

--Apple-Mail-3--836069903
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed

Hi,

What is the difference between

obj.kind_of?(Customer)

and

obj.class =3D=3D Customer.class

?
The earlier works but the latter don't. Why?
Thanks,

G=E1bor

"Never trust a computer you can't throw out a window." - Steve Wozniak


--Apple-Mail-3--836069903--

 

[Jason Foreman]

Hi,
=20
What is the difference between
=20
obj.kind_of?(Customer)
=20
and
=20
obj.class =3D=3D Customer.class
=20
?
The earlier works but the latter don't. Why?
Thanks,

obj.class =3D=3D Customer

Customer.class =3D=3D Class

 

[James Edward Gray II]

Hi,

What is the difference between

obj.kind_of?(Customer)

and

obj.class =3D=3D Customer.class

?
The earlier works but the latter don't. Why?

Customer is a "class", so when you ask for Customer.class you're =20
probably getting Class as an answer. I believe what you meant is:

obj.class =3D=3D Customer

Another way to write that is using the "case equals" method (used to =20
resolve case statements):

Customer =3D=3D=3D obj

Hope that helps.

James Edward Gray II

 

[Gábor SEBESTYÉN]

--Apple-Mail-4--835152486
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed

obj.class =3D=3D Customer

Indeed, that's what I wanted.
Thanks,

G=E1bor

"Rekl=E1m - Ez az emil recikl=E1lt elektronok felhaszn=E1l=E1s=E1val =
k=E9sz=FClt!"


--Apple-Mail-4--835152486--

 

[Robert Klemme]

Customer is a "class", so when you ask for Customer.class you're
probably getting Class as an answer. I believe what you meant is:

obj.class == Customer

Another way to write that is using the "case equals" method (used to
resolve case statements):

Customer === obj

Hope that helps.

James Edward Gray II

Just for the sake of completeness: obj.kind_of? Customer is equivalent to
Customer === obj while obj.class == Customer has different semantics. The
latter form test for the exact class only while both former variants test
for classes and sub classes.

Kind regards

robert

 

[Gene Tani]

Hmm, seems to be few ways to test/monitor
membership/inheritance/mix-in-ness:

Object#kind_of?, #is_a?, #instance_of?, #type (deprecated), #class

Module#ancestors, #included_modules

Class#inherited

MyClassname === myobj

 

[Daniel Brockman]

Hmm, seems to be few ways to test/monitor
membership/inheritance/mix-in-ness:

Indeed.

Object#kind_of?, #is_a?,

Module#ancestors,

MyClassname === myobj

Interestingly, you've listed these in order of preference:

* foo.kind_of? Foo --- perfect
* foo.is_a? Foo --- unrubyish due to `is_*?'
* foo.class.ancestors.include? Foo --- long-winded and confusing
* Foo === foo --- confusing and unnecessary

Of course, when checking multiple cases, this is perfect:

case foo
when Foo
...
when Bar
...
when Baz
...
end

However,

#instance_of?, #type (deprecated), #class

I'd order the ways of checking the exact class like this:

* foo.class == Foo --- perfect
* foo.instance_of? Foo --- obscures the semantics
* foo.type == Foo --- deprecated

Module#included_modules, Class#inherited

(I left these out because they are normally useless, and primarily
serve as hooks to make obscure object-system hackery possible.)

In the same vein, there's alse Class#superclass.

 

[Gene Tani]

Listened to Alex Martelli talk about decorators, metaclasses and method
resolution order in Python. Not easy to draw direct parallels to ruby

 

[jason r tibbetts]

Indeed.




Interestingly, you've listed these in order of preference:

* foo.kind_of? Foo --- perfect
* foo.is_a? Foo --- unrubyish due to `is_*?'

What's unrubyish about is_a?

 

[Daniel Brockman]

What's unrubyish about is_a?

It's customary not to prefix predicates by `is_'.
For instance, it's `empty?', not `is_empty?'; `frozen?',
not `is_frozen?'; `finite?', not `is_finite?', etc.

foo.a? Foo

On the other hand, that doesn't read very well.

Actually, I guess you could argue that the no-`is_' convention
doesn't apply for parameterized methods.

 

[Devin Mullins]

It's customary not to prefix predicates by `is_'.
For instance, it's `empty?', not `is_empty?'; `frozen?',
not `is_frozen?'; `finite?', not `is_finite?', etc.

foo.a? Foo

On the other hand, that doesn't read very well.

Actually, I guess you could argue that the no-`is_' convention
doesn't apply for parameterized methods.

Well, is_empty? is different from is_a?, in that "a" is not a property
of the object -- rather, it's just part of a sentence-like phrase. I
think the no "is_" convention just came about because it was three
characters that communicated nothing, and hence were unnecessary. As you
saw, #a? looks weird, so the "is_" communicates something important in
this case.

But really, I don't care which you prefer. (No offense. I don't have
any problem with using is_a?, as it just plain looks more readable to
me. (It doesn't hurt that it's shorter, too. )

Devin

 

[Daniel Brockman]

Well, is_empty? is different from is_a?, in that "a" is not a
property of the object -- rather, it's just part of a sentence-like
phrase.

Hi Devin,

Good point. You are right, of course.

I think the no "is_" convention just came about because it
was three characters that communicated nothing, and hence were
unnecessary. As you saw, #a? looks weird, so the "is_" communicates
something important in this case.

You're right again.

But really, I don't care which you prefer. (No offense. I don't
have any problem with using is_a?, as it just plain looks more
readable to me. (It doesn't hurt that it's shorter, too. )

Another argument against it is the fact that the indefinite article
will be wrong for about half the cases (e.g., `foo.is_a? Array').
Yet another that it doesn't look very good when used with adjectival
arguments (e.g., `foo.is_a? Enumerable').

Interestingly, `is?' works really well for adjectival arguments:

foo.is? Enumerable foo.is? Observable

It's actually not that bad for substantival arguments either:

foo.is? String foo.is? Array

(Note that `kind_of?' works well in all these cases:

foo.kind_of? Enumerable foo.kind_of? Observable

foo.kind_of? String foo.kind_of? Array)

 

[Devin Mullins]

Interestingly, `is?' works really well for adjectival arguments:
foo.is? Enumerable foo.is? Observable
It's actually not that bad for substantival arguments either:
foo.is? String foo.is? Array

Indeed, I like the look of that. I imagine, however, he added the _a
because he didn't want to crowd the method namespace (I assume the same
reason he changed id to object_id).

(Note that `kind_of?' works well in all these cases:
foo.kind_of? Enumerable foo.kind_of? Observable
foo.kind_of? String foo.kind_of? Array)

I can see that. I guess it's just that I'm not used to thinking of
instances as "kinds." Also "kind of" comes off sounding like
"approximately," which is kind of weird. I'm obviously too closed-minded
for Ruby.

Devin

 

[Daniel Brockman]

Indeed, I like the look of that. I imagine, however, he added the _a
because he didn't want to crowd the method namespace (I assume the
same reason he changed id to object_id).

I don't think `is?' crowds it any more than `is_a?'. Rather, I guess
he used the latter because `is-a' was a well-established term.

I can see that. I guess it's just that I'm not used to thinking of
instances as "kinds."

Fair enough. Indeed, when functional programming geeks talk about
type systems they will often distinguish between `types' and `kinds'.

Also "kind of" comes off sounding like "approximately," which is
kind of weird.

Granted, but that's actually not a completely unsuitable connotation.
The Collaborative International Dictionary of English has the
following to say about the term ``kind of'':

A kind of, something belonging to the class of; something
like to; -- said loosely or slightingly.

Keep in mind that `kind_of?', unlike `instance_of?', does not check
strict class--instance relationships, but allows subtype instances.

I'm obviously too closed-minded for Ruby.

I don't know... you seem pretty open-minded to me.