Re: The duck's backside

On Fri, May 30, 2008 at 3:12 PM, Mark Wilden <[e-mail]> wrote:

> If classes are not categories, what are they?

A convenient tool for specifying behavior and using inheritance and
mixins for code reuse.
At least that is what Ruby classes give us. Free to you to apply
paradigms that can be implemented with this tool. To claim that Ruby
classes *are* that kind of paradigms does not meet my approval. Maybe
classes are very easily  to be used as categories but I do not know
that.
>
> I've done a lot of C++, and I remember when RTTI (runtime type information)
> was introduced. I was pretty strongly against its use, believing that
> polymorphism through virtual functions was the way to "branch" on type. I
> would have strongly avoided code like v === Numeric.
For a very good reason, because it is Numeric === v. ;)
But I feel a need to to justify my original reply to OP, he just
really needed that kind of check to make something work quickly, so I
showed him how to do it.
I however completely agree with you that code like that rings an alarm bell.
>
> As I would avoid it today, in Ruby. We're actually talking about something
> that I think should be rare, which is branching on type.
I boldly (my turn now ;) state that there is no type in Ruby, but I
know what you mean and still agree!
>We're only doing it
> to validate parameters. In good Ruby, we would not do this, relying on the
> runtime to tell us when we're using the wrong type. To me, duck typing
> doesn't mean "ask me if I quack" as much as "quack, you!".
I would not like to ban early failure checks like that totally. Again
it just rings an alarmbell, but in some contexts TTD is difficult and
then extremely defensive programming might be in order,.
> So I think this
> whole discussion is about an edge case.
Right indeed, this was forgotten OP even stated so, good point.
>> Now, for the simple case of a Numeric, we're probably over-analyzing it.
>
> Yes, I don't think I would have made the same case for a less basic class.

For me there is a substantial difference though, and my bad that I did
not mention it in my
original post. Checking things like Integer ===, or String === are
surely less errorprone than
MyOwnClass ===, as I strongly feel that the randomly chosen Ruby
programmer will mess around with them less, especially when it comes
to override or revoke standard behavior.
>
> However, I still think using responds_to? to identify an object's type is
> risky.
It is even plain wrong, it specifically ask if behavior carrying a
given name is implemented or not, well you put that quite nicely into
the next sentence anyway :)
> As I said, it relies upon a much larger namespace than class
> constants, hence much more chance for accidental positives (e.g., #draw
> meaning different things to different objects).

>
>>> But I'm finding these remarks about "attititude" kind of amusing. It's
>>> like Ruby isn't a tool, it's a "mindset." We don't forgo something
>>> like Numeric === v because it's _wrong_ (the OP in fact said it was
>>> slightly more readable), but because Ruby has duck-typing,
It really feels wrong because indeed each tool creates its own
mindset, yet people are quite tolerant with it, but you just have to
remember all the time in Ruby (not as a mindset but as a simple
consequence of how Ruby works)

Class != Behavior

>> There's nothing wrong with that. But I hope most of us  forgo it in favor
>> of:
>>
>> data.each { |datum|
>>  do_something_with datum
>> }
Amen.
>>
>> Which ends up being more readable, among other things.
>
> Exactly. It has absolutely nothing to do with Ruby's "mindset," or "the way
> we do things in Ruby." We choose the latter because it's better, not because
> it's the Ruby way.
>It's the other way around: it's the Ruby way because it's
> better; not that it's better because it's the Ruby way. The former attitude
> is pragmatic, the latter is religious.
Strangely enough I see it the other way round:
"It is better" ( a very dangerous statement indeed) seems dogmatic to me.
using the mindset implied by semantics OTOH feels very pragmatic.
>> Firstly, #class doesn't provide any way to be in multiple categories. Ruby
>> doesn't support multiple inheritance.
You just have come to the end of your own argument I am afraid. Not
being an expert
I might be wrong of course, do you mean that mixins are not powerfull
enough to satisfy that model?
Robert