[RCR] array or with non-array

[David A. Black]

Hi --

|But, this wasn't really what my #1 above was about. It was
|about overloaded methods where the functionality is
determined
|by looking at the type of the arguments. One example would
be
|String#[arg]:
|
|str[fixnum] => fixnum or nil
|str[range] => new_str or nil
|str[regexp] => new_str or nil
|str[other_str] => new_str or nil
|
|All of these behave very different. The way you figure out
|what to do is based on type - which goes against the
|duck-typing philosophy. I think the only advantage of
|combining all of these functions into one method is
|convenience. But, by doing so you loose the ability to
handle
|more general duck-typed/polymorphic arguments.

class != type. Type is at the heart of duck-typing; class isn't

I'm more of a purist and thus prefer the purity over the
convenience. And I know there may not be many in my camp.

I'm not clear on how you define purity or purism, but it doesn't
bother me that array[1] and array[1..3] do different things. Maybe
it's because a few core methods where a few core classes are
hard-coded allows for so much richness later, or something along those
lines -- a kind of bootstrapping.


David

 

[Eric Mahurin]

Hi --
=20
On Thu, 4 Aug 2005, Eric Mahurin wrote:
=20

|But, this wasn't really what my #1 above was about. It was
|about overloaded methods where the functionality is
determined
|by looking at the type of the arguments. One example would
be
|String#[arg]:
|
|str[fixnum] =3D> fixnum or nil
|str[range] =3D> new_str or nil
|str[regexp] =3D> new_str or nil
|str[other_str] =3D> new_str or nil
|
|All of these behave very different. The way you figure out
|what to do is based on type - which goes against the
|duck-typing philosophy. I think the only advantage of
|combining all of these functions into one method is
|convenience. But, by doing so you loose the ability to
handle
|more general duck-typed/polymorphic arguments.

=20
class !=3D type. Type is at the heart of duck-typing; class
isn't

Huh? Where do you get that? Duck-typing is about not caring
about what the type/class the object is. Duck-typing in the
purest sense is calling the methods of the arguments without
regard to what the class of the object is.

In the above, the functionality is clearly affected by the
class. If you wrote the single arg String#[] above you'd have
something like this:

def [](i)
if Fixnum=3D=3D=3Di
# retrieve character at index i
elsif Range=3D=3D=3Di
# retrieve slice designated by the Range i
elsif Regexp=3D=3D=3Di
# retrieve slice found by the Regexp i
elsif String=3D=3D=3Di
# retrieve slice that is the same as String i
else
raise
end
end

That is far from duck-typing. This very much cares about the
type/class of the argument. It both restricts the class and
makes decisions about what functionality to have based on that
type. You could use respond_to? instead of klass=3D=3D=3D to help,
but that would like just introduce ambiguities about what
functional branch to take - you'd have to favor one case over
another. Implementation-wise, I don't have a problem with
choosing how to operate based on class, but this decision
should not affect functionality - only performance.



=09
____________________________________________________
Start your day with Yahoo! - make it your home page=20
http://www.yahoo.com/r/hs=20
=20

 

[David A. Black]

Huh? Where do you get that? Duck-typing is about not caring
about what the type/class the object is. Duck-typing in the

Class is irrelevant, but you'd be well-advised to care about what the
type is, or you'll find yourself with a lot of NoMethodErrors

purest sense is calling the methods of the arguments without
regard to what the class of the object is.

An object's type is the sum of all of its capabilities. Duck typing
involves focusing on an object's capabilities -- its type -- and not
worrying about its class. You also don't have to "worry" about its
type (and I agree with those who say that duck typing does not mean
sticking respond_to? everywhere). But you are dealing with type --
dealing with it, in the sense of making assumptions about it, writing
code governed by those assumptions, etc. -- and not dealing with
class.

I like Jim Weirich's characterization of Ruby as "a duck-typed
language", because it captures the fact that, in a sense, one is
always doing duck typing in Ruby. That's also why I always feel
uneasy with meta-concepts like the "duck type" of an object. What
people sometimes call the "duck type" of an object, I call simply the
type of the object. Duck typing, in that respect, is a way of
describing an approach to programming that arises very organically
from Ruby.


David

 

[Eric Mahurin]

Huh? Where do you get that? Duck-typing is about not caring
about what the type/class the object is. Duck-typing in

the
=20
Class is irrelevant, but you'd be well-advised to care about
what the
type is, or you'll find yourself with a lot of NoMethodErrors

=20

purest sense is calling the methods of the arguments without
regard to what the class of the object is.

=20
An object's type is the sum of all of its capabilities. Duck
typing
involves focusing on an object's capabilities -- its type --
and not
worrying about its class. You also don't have to "worry"
about its
type (and I agree with those who say that duck typing does
not mean
sticking respond_to? everywhere). But you are dealing with
type --
dealing with it, in the sense of making assumptions about it,
writing
code governed by those assumptions, etc. -- and not dealing
with
class.
=20
I like Jim Weirich's characterization of Ruby as "a
duck-typed
language", because it captures the fact that, in a sense, one
is
always doing duck typing in Ruby. That's also why I always
feel
uneasy with meta-concepts like the "duck type" of an object.=20
What
people sometimes call the "duck type" of an object, I call
simply the
type of the object. Duck typing, in that respect, is a way
of
describing an approach to programming that arises very
organically
from Ruby.[/QUOTE]


Whatever your definition of type is, a method should not care
(i.e. check) about the types of its arguments. It should just
assume that the arguments have the capabilities that it wants.=20
That is is core of duck-typing, is it not?

I also think your definition of type (or duck-type) is too
restrictive. Instead of "An object's type is the sum of all of
its capabilities", it should be "An argument's type is the sum
of its capabilities that the method uses or documents that it
may use". Every method argument has its own duck-type.

But, back to the original thing that spawned this discussion -
the String#[] method. I claim that this violates the spirit of
duck-typing all over the place because of the class (or type)
checking done to accomplish multiple functions. Do you claim
it is duck-typed? If so, show me how you could get the
multiple functions that it has and still be duck-typed.

My point is that when coding ruby, we are encouraged to use
duck-typing, but the ruby library itself does not. Seems kind
of hypocritical.



=09
____________________________________________________
Start your day with Yahoo! - make it your home page=20
http://www.yahoo.com/r/hs=20
=20

 

[David A. Black]

Hi --

Whatever your definition of type is, a method should not care
(i.e. check) about the types of its arguments. It should just
assume that the arguments have the capabilities that it wants.
That is is core of duck-typing, is it not?

I guess it usually involves method arguments, though only indirectly
-- meaning, it's about how objects are treated, and what assumptions
are made about them, whether or not they arrived on the scene as
method arguments (though I guess that's the usual scenario).

I also think your definition of type (or duck-type) is too
restrictive. Instead of "An object's type is the sum of all of
its capabilities", it should be "An argument's type is the sum
of its capabilities that the method uses or documents that it
may use". Every method argument has its own duck-type.

My definition of "type" isn't restricted to method arguments, so your
definition doesn't work as a drop-in replacement

I don't find the concept of a "duck-type" very useful. *Type* in
Ruby, without the duck, already reflects something dynamic, flexible,
unrestricted by class/module ancestry, and so on. Duck typing is a
way of leveraging type, in this sense.

But, back to the original thing that spawned this discussion -
the String#[] method. I claim that this violates the spirit of
duck-typing all over the place because of the class (or type)

(definitely class, in this case)

checking done to accomplish multiple functions. Do you claim
it is duck-typed? If so, show me how you could get the
multiple functions that it has and still be duck-typed.

My point is that when coding ruby, we are encouraged to use
duck-typing, but the ruby library itself does not. Seems kind
of hypocritical.

You're turning it into a game of "Simon Says" -- "Uh oh, you branched
on class membership: you're out!" I think it's a little more
subtle than that. As I said before, I tend to be accepting of
hard-coded class-based things when they're in the core, since it
provides such a flexible and powerful programming environment and
there's no mandate to base one's Ruby style on the class-name checks
in the C source.


David

 

[Joel VanderWerf]

Class is irrelevant, but you'd be well-advised to care about what the
type is, or you'll find yourself with a lot of NoMethodErrors



An object's type is the sum of all of its capabilities. Duck typing
involves focusing on an object's capabilities -- its type -- and not
worrying about its class. You also don't have to "worry" about its
type (and I agree with those who say that duck typing does not mean
sticking respond_to? everywhere). But you are dealing with type --
dealing with it, in the sense of making assumptions about it, writing
code governed by those assumptions, etc. -- and not dealing with
class.

I like Jim Weirich's characterization of Ruby as "a duck-typed
language", because it captures the fact that, in a sense, one is
always doing duck typing in Ruby. That's also why I always feel
uneasy with meta-concepts like the "duck type" of an object. What
people sometimes call the "duck type" of an object, I call simply the
type of the object. Duck typing, in that respect, is a way of
describing an approach to programming that arises very organically
from Ruby.


David

warn "philosophical pootling ahead"

Maybe we need to begin talking about ruby not just as a language with
formal, constructive meanings, but as a "language game" in the sense of
Wittgenstein, with meaning accruing through use.[1]

Obviously, any particular ruby program has a constructive meaning
assigned by the interpreter. But that doesn't capture the way meanings
change as a library is used in different ways over time. I can write a
library that works in one way with all the inputs I've considered, but
because those inputs are "duck typed", there exist future
interpretations of my library, based on inputs with unforseen
implementations, that cannot be explained in terms of the "types" I was
thinking of when I wrote my library.

[1] http://plato.stanford.edu/entries/wittgenstein/#Mea

 

[Nikolai Weibull]

Sometimes wish that [3, 5, 13] | [8] can be written as [3, 5, 13] | 8
that ary |= 42 would be possible.

chris2 pointed out that it would be inconsistent with [1,2,3] + 4.
maybe let + append 4 to the array?

Sorry for such a late response, but I just had to ask:

Why not just use Array#<<? It works fine, is unambiguous, and neither
the suggestions for Array#| nor that for Array#+ do anything that
Array#<< doesn't already. Or am I missing something vital here?,
nikolai

 

[Nikolai Weibull]

Simon Strandgaard wrote:

Sometimes wish that [3, 5, 13] | [8] can be written as [3, 5, 13] | 8
that ary |= 42 would be possible.

chris2 pointed out that it would be inconsistent with [1,2,3] + 4.
maybe let + append 4 to the array?

Sorry for such a late response, but I just had to ask:

Why not just use Array#<<? It works fine, is unambiguous, and neither
the suggestions for Array#| nor that for Array#+ do anything that
Array#<< doesn't already. Or am I missing something vital here?,

<< is destructive, + copies, | copies but doesn't add it if it's
already in there.

Ah, of course; silly me.

Still, I don't see what you are trying to say?

Huh?,
nikolai