On Wednesday 28 May 2008 21:45:25 Mark W. wrote:
On May 28, 2008, at 6:25 PM, David M. wrote:
I think your use case had something to do with a fragile web
service, so this
actually could make a lot of sense to you – it might even be worth
checking
if it’s an Integer.Wasn’t my use case.
My mistake, sorry about that.
Nice talking, though! I’ve been on ruby-talk less than a day, and I’m
happy to
be here.
On Wed, May 28, 2008 at 6:23 PM, Mark W. [email protected] wrote:
Well, the desired goal is in fact to recognize objects that are numeric. One
of the purposes of classes in OOP is to categorize things.
Not really, no. That reflects an attitude that has more to do with
C++ or Java than with OOP. Not everything which behaves as a number
will inherit from Numeric, so that makes it useless and potentially
misleading as a categorization tool.
If you want you know whether an object is in some category in an OO
way, you come up with a way to ask it. E.g. if you want to know if an
object is iterable, you ask it if it responds to #each. Or you simply
treat it as if it is in that category, and see what happens. If you
want to assert that object to must be in a category, you tell it to
convert itself (and it will tell you if it can’t).
With that said, I’m not really on the fanatical duck-typing end of
things either. I believe there is value in doing proactive contract
checking at what I will call for lack of a better term “package
boundaries”. Duck-typing errors are not always obvious or easy to
track down. I like to have firewalls that I can be fairly confident
will catch faulty assumptions in a straightforward and obvious way,
without having to work back along the chain from a secondary or even
tertiary side-effect of an object failing to quack. For this reason
I’ve been known to put pre- and post-condition assertions in layers of
code that interact with third-party code.
–
Avdi
Home: http://avdi.org
Developer Blog: Avdi Grimm, Code Cleric
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com
On 28 May 2008, at 23:23, Mark W. wrote:
was for a reason.
I used to_int because it happened to be the synonym that popped into
my head at the time I was writing the code. It probably makes more
sense to use to_i though as that’s often implemented outside the
Numeric class hierarchy for objects which can be represented by an
integer.
Also, context matters. If Cowboy and Artist are both in a GUI
widget library,
that Cowboy is asking for trouble.That’s true, but it wasn’t my point. The question is whether all
methods with the same name in all active classes should be
semantically equivalent. I think that’s a rather larger assumption
than that Numeric means “numeric.”
Numeric may well mean “numeric” in some particular sense, but that is
only a subset of all objects which may have a valid numeric
representation. As I said, you’re applying a static typing mindset to
a place where it’s not necessary and whilst Ruby will let you do that,
in the long term you’ll find yourself doing much more work with very
little (if any) gain in software robustness. In fact if you’re writing
a library you’ll introduce additional fragility to code interfacing
with it because Ruby programmers generally expect Duck Typing and
write accordingly.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On 28 May 2008, at 21:09, Mark W. wrote:
The only point of using Ruby (or any other tool in the universe) is
to get a job done.I would never use a Ruby feature just because
Ruby makes it possible.Numeric === v is not a static typing convention (see Type system - Wikipedia)
. It’s just OOP. It says in computer-understandable terms exactly
what you expressed in English: “v is numeric.”
No, it states that v inherits from the base class Numeric, and that is
very much a static typing mindset, just projected onto an OO idiom.
However Ruby is very much a dynamic language in which an instance of
an object is not defined purely in terms of a chain of class
inheritance, or even of mix-ins because an instance can have new
methods directly attached to it. This being the case it makes much
more sense to see if an instance responds to a given message of
interest and then to act accordingly than to try and make assumptions
based upon incomplete inheritance information.
I don’t even know what the ability to respond to :to_int means. Does
that mean the entity is numeric? Does a numeric string qualify? Does
a floating point number qualify? Could Array support this method?
Does every class that responds to to_int do semantically equivalent
things? (think Cowboy#draw and Artist#draw). The only way to tell is
to test it or look it up.
Yes. But as to_i, to_int, to_f, to_a, to_s and to_str are well known
messages you can have a high confidence that when these are present in
an instance they mean exactly what you expect them to mean. In
practice this extends to a much larger vocabulary.
This doesn’t make it “marginally” less readable than Numeric === v,
IMO.Different strokes, of course…
Exactly. If you don’t like Duck Typing don’t use it. It’s perfectly
possible to design code in Ruby similarly to the way you would in Java
or C++ if that’s what you’re comfortable with. Just don’t be surprised
if you find yourself writing a lot more code than is necessary.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On May 28, 2008, at 8:59 PM, Avdi G. wrote:
On Wed, May 28, 2008 at 6:23 PM, Mark W. [email protected] wrote:
Well, the desired goal is in fact to recognize objects that are
numeric. One
of the purposes of classes in OOP is to categorize things.Not really, no. That reflects an attitude that has more to do with
C++ or Java than with OOP.
I must respectfully disagree. I learned OOP (in 1989) before C++ was
even hardly available on PCs, much less Java. The OOP language I
learned was an amalgam of Smalltalk and Lisp. I cut my teeth on
Bertrand Meyer, Adele Goldbert, Brad Cox, and Grady Booch. I can say
quite categorically, that in OOP, classes are ways to generalize. You
generalize based on characteristics and behaviors. A class is not
simply a random collection of methods. It would be rather useless if
class was unrelated to category.
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, and why use
Ruby if you can’t duck type? I hope I’m not the only person to see how
totally back-asswords this kind of argument is.
Not everything which behaves as a number will inherit from Numeric,
so that makes it useless and potentially misleading as a
categorization tool.
And not everything that implements #to_int will be numeric, or can
even be converted to a number in a meaningful way for a context that
expects numbers. It’s implementer’s choice. However, the use case
might be that any object with that method is fine and dandy. In that
case, I totally agree that checking for response to it is reasonable,
if not 100% reliable. But if we’re looking for Fixnums, Floats, and
other builtin classes, then checking again Numeric seems
straightforward.
The presence of a method called #each does not make an object
iterable. The only way that would be possible is if everyone who wrote
an #each method decided that was what it meant. What does show far
more accurately whether it’s iterable is whether it includes
Enumerable. Including Enumerable shows that the #each method is for
iterating, rather than pricing, or something else.
If you want you know whether an object is in some category in an OO
way, you come up with a way to ask it.
True. And often the most straightforward and fundamental way to do
that is to call its #class method.
I like duck-typing. It distinguishes great OOP languages like
Smalltalk and Ruby from wannabes like C++ and Java. But classes are
not simply random collections of methods. Their power is indeed to
categorize and generalize objects, which can be specialized with
inheritance (another old school concept, I suppose). So if I can solve
a programming problem simply by asking what builtin class an object
is, as opposed to seeing if it responds to a certain method name,
knowing nothing about what that method actually does, I’ll go with the
former. It’s just the simplest thing that could possible work. But
wait–maybe that hoary criterion is out of fashion too?
///ark
From: “Mark W.” [email protected]
So if I can solve
a programming problem simply by asking what builtin class an object
is, as opposed to seeing if it responds to a certain method name,
knowing nothing about what that method actually does, I’ll go with the
former.
There are more ducks in heaven and earth, Horatio, than are
dreamt of in your philosophy.
require ‘delegate’
=> true
x = SimpleDelegator.new(123)
=> 123
x.class
=> SimpleDelegator
x.kind_of? Numeric
=> false
x.is_a? Numeric
=> false
x.respond_to? :to_int
=> true
x.to_int
=> 123
Regards,
Bill
In article [email protected],
Mark W. [email protected] wrote:
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, and why use
Ruby if you can’t duck type? I hope I’m not the only person to see how
My code worked before I started the thread. Like many posts around here
I asked how to make it more Ruby. The reason being that I believe the
language was designed by better programmers than myself, and that wholly
embracing their philosophy will bring me farther than just applying what
I learned in ‘lesser’ languages. That might change once I transcend all
implications of duck typing 
Le 29 mai à 06:45, Eleanor McHugh a écrit :
On 28 May 2008, at 23:23, Mark W. wrote:
little (if any) gain in software robustness. In fact if you’re writing
a library you’ll introduce additional fragility to code interfacing
with it because Ruby programmers generally expect Duck Typing and
write accordingly.
BTW, your code makes in fact two assumptions :
Wouldn’t it be better to write this :
@post “first=#{a}&” + (b.nil? ?
“second=ignored&third=#{v.to_int}” :
“second=#{v.to_int}&third=ignored”)
Ellie
Fred
On Thursday 29 May 2008 00:59:42 Mark W. wrote:
I must respectfully disagree. I learned OOP (in 1989) before C++ was
even hardly available on PCs, much less Java. The OOP language I
learned was an amalgam of Smalltalk and Lisp.
That’s interesting.
It’s my understanding that Ruby borrows its concept of “sending
messages” from
Smalltalk, which lets us do things like #send and #method_missing.
I can say
quite categorically, that in OOP, classes are ways to generalize. You
generalize based on characteristics and behaviors. A class is not
simply a random collection of methods. It would be rather useless if
class was unrelated to category.
I’m going to have to respectfully disagree here. Having done
prototype-based
development in JavaScript, as I understand it, it’s far easier to
implement a
class-based system on top of a prototype system than the other way
around.
In fact, I’ve seen it done, in various ways, with varying degrees of
success
and usability.
Unless you are going to have branching based on type – that is, simple
method
overloading (as in C++ and friends) – I don’t see as much point to a
rigid
type system.
It boils down to: Why should I care whether I’m being passed a number or
something which merely behaves like a number? Why should I care if I’m
being
passed a string or an array of characters?
Or even, why should I care if I’m being passed a real local object, or a
proxy
to a remote object? Check this out:
http://ruby-doc.org/core/classes/DRb/DRbObject.html
Now, for the simple case of a Numeric, we’re probably over-analyzing it.
There’s not a huge amount of potential for replacing it with something
Numeric-like that does the same job, and we can easily see where relying
on
to_i might (in VERY unlikely circumstances) give us something we don’t
want.
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,
Well, there is some truth to that – as an example, Ruby completely
lacks
anything resembling the C for loop. If that’s what you’re expecting, you
have
to build it out of a while loop:
i=0
while i < data.length
do_something_with data[i]
i += 1
end
There’s nothing wrong with that. But I hope most of us forgo it in
favor of:
data.each { |datum|
do_something_with datum
}
Which ends up being more readable, among other things.
It’s not absolute. There are cases where you want traditional looping
constructs instead of Ruby iterators, and there are cases you want
classes
instead of duck typing. But these are the exception, not the rule.
I won’t stop you from using Ruby if you’d rather build for loops. Maybe
you’ll
get better at it:
data.length.times { |i|
do_something_with data[i]
}
But if you do that, I don’t understand why you’re using Ruby. Again,
nothing
wrong with it – do whatever makes you happy, and maybe you’re right and
I’m
wrong. But I doubt I’ll ever understand it.
However, the use case
might be that any object with that method is fine and dandy. In that
case, I totally agree that checking for response to it is reasonable,
if not 100% reliable. But if we’re looking for Fixnums, Floats, and
other builtin classes, then checking again Numeric seems
straightforward.
Can you outline a few real-world examples, where it’s OK to get a
descendant
of Numeric, but not something which merely implements to_i or to_f?
If you want you know whether an object is in some category in an OO
way, you come up with a way to ask it.True. And often the most straightforward and fundamental way to do
that is to call its #class method.
Not really.
Firstly, #class doesn’t provide any way to be in multiple categories.
Ruby
doesn’t support multiple inheritance.
Second, given no context, there’s not really any way I could override
class to
provide multiple membership. I’m either an Array or I’m a String. I
can’t be
both.
(Actually, I could probably pull something incredibly sneaky by
returning an
object which pretends to be a class, and returns true when compared to
other
classes on some list – but I think I’d have to override some methods in
Class and/or Module to make it bulletproof.)
Now, we could meet halfway. All Numerics define #integer?, which
responds True
for Integer and Bignum, and false for everything else. Object defines
#nil?,
which is true for NilClass and false for everything else. And, worst
case,
calling the object’s own #kind_of? method gives me a place to override
that
type check – I don’t believe that the Class === obj syntax allows that.
Their power is indeed to
categorize and generalize objects, which can be specialized with
inheritance (another old school concept, I suppose).
Inheritance can be approximated in Ruby with mixins. In JavaScript, it’s
actually possible to write mixin functionality from the ground up –
create a
new class, and define it as a collection of methods from selected other
classes, plus a new collection you define right here.
I’m not sure I know how to implement ad-hoc prototypes and things like
#define_method from pure inheritance semantics. I am sure I can create
inheritance out of pure prototype semantics.
Hi –
On Thu, 29 May 2008, Mark W. wrote:
I must respectfully disagree. I learned OOP (in 1989) before C++ was even
readable), but because Ruby has duck-typing, and why use Ruby if you can’t
duck type? I hope I’m not the only person to see how totally back-asswords
this kind of argument is.
Dave T., who coined the term “duck typing”, has described it as
“a way of thinking about programming in Ruby.” So it is, in that
sense, a matter of attitude. The term has been beaten and battered
over the years to the point of unrecognizability, but it’s pretty
simple in its original form.
Duck typing, as a way of thinking, meshes nicely with Ruby, as a tool,
because of how Ruby objects are engineered: the only thing that you
can measure with certainty is what an object does when you send it a
message. You can ask it what its class is, what its ancestors are,
what methods it responds to, and so forth… but in the end, you hit
the singularity: the sending of the message. At that moment, whatever
is going to happen will happen.
The idea of duck typing, as I understand it, is to embrace this
inalterable fact about Ruby objects, rather than try to wish it away,
with ancestry checks and the like. This makes sense to me; it stands
to reason that a language with objects whose types can change during
runtime would be well-served by a programming style that deals as
directly and economically as possible with precisely that condition.
David
On Thu, 2008-05-29 at 07:23 +0900, Mark W. wrote:
One of the purposes of classes in OOP is to categorize things.
One of the weaknesses of classic Booch, et al OOP is that one of the
purposes of classes in OOP is to categorize things.
Classes in classic OOP languages conflate a variety of concepts and cram
them into one structure which does none of them particularly well:
1. Classes are the unit of state.
2. Classes are the unit of access control.
3. Classes are the unit of functional dispatch.
In extreme cases (Java, I’m looking at you here!) classes are also the
unit of packaging. (In other classic OOP language cases the unit of
packaging is an ad-hoc mess. C++ I’m looking at you here!)
I personally have always preferred the Dylan model (which I understand
comes from the CLOS model, watered-down somewhat):
1. Classes are the unit of state.
2. Modules (and, to a point, libraries) are the unit of access
control.
3. Generic functions are the unit of functional dispatch.
(Multi-methods! Yay!)
And, unlike Java or C++, libraries are the unit of packaging.
I found that neatly layered structure of orthogonal concerns modelled by
separate mechanisms a breath of fresh air after coming from the bizarre
world of class OOP.
Hi –
On Thu, 29 May 2008, Robert D. wrote:
I have to admit that I was quite disappointed that my implementation
of traits got so few feedback. That is not the personal disappointment
that comes simply for the reason that one wants to share a project and
cannot as it does not interest others, that is a risk to take of
course ;).
It surprised me though that Rubiests that I learnt to like and
respect, like e.g. you Dave, still use the terms “types” and “classes”
s/Dave/David/ 
as
if they were not in contradiction to what they are saying about duck
typing afterwards.
Sorry, I’m not sure which contradiction you’re talking about. Can you
clarify?
David
On Thu, May 29, 2008 at 12:37 PM, David A. Black [email protected]
wrote:
The idea of duck typing, as I understand it, is to embrace this
inalterable fact about Ruby objects, rather than try to wish it away,
with ancestry checks and the like. This makes sense to me; it stands
to reason that a language with objects whose types can change during
runtime would be well-served by a programming style that deals as
directly and economically as possible with precisely that condition.
I have to admit that I was quite disappointed that my implementation
of traits got so few feedback. That is not the personal disappointment
that comes simply for the reason that one wants to share a project and
cannot as it does not interest others, that is a risk to take of
course ;).
It surprised me though that Rubiests that I learnt to like and
respect, like e.g. you Dave, still use the terms “types” and “classes”
as
if they were not in contradiction to what they are saying about duck
typing afterwards.
With traits we are exactly talking ducktyping, we combine behavior,
which we try organize intelligently and forget about inheritance and
is_a? modeling. It really gives us the chance to implement
applications without abusing of inheritance. The beauty of Ruby is of
course that single inheritance and Mixins are still available for
projects where this is appropriate, and there are many.
The bold statement I will make now is the following: Whenever a
projects seems best suited to use ducktyping as its dominant design
scheme, traits (as e.g. in Squeak) or prototypes ( as e.g. in
Javascript) somehow seem a more natural approach than classes and
mixins.
Now using mixins extensively (pun intended) is a good thing especially
if we refrain from abusing is_a?, Module#=== ed altri.
It can lead to beautiful designs(1), but so can using traits and
prototypes
(1) beware of the double inclusion trap though
Cheers
Robert
–
http://ruby-smalltalk.blogspot.com/
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein
On Thu, May 29, 2008 at 1:35 PM, David A. Black [email protected]
wrote:
s/Dave/David/
s /^/So sorry, why does this always happen to me?/as
if they were not in contradiction to what they are saying about duck
typing afterwards.Sorry, I’m not sure which contradiction you’re talking about. Can you
clarify?
Contradiction is maybe a too strong a word, let me put it like this,
IIUC, you and others made some interesting points about static
modeling and ducktyping as one way of a more dynamic approach fitting
Ruby’s dynamic nature quite well. As many people on this list I
completely adhere to this statement.
I however have always thought that it was kind of exploring an
interesting road without trying some new paths. E.g. using prototypes
instead of inheritance and mixins or traits. Prototypes have been
around for quite some while as a result of Ara’s work, though I am
afraid it is broken now.
I have delivered a more primitive implementation (very slow 10slower
than mixins) of prototypes and a quite acceptably performing traits
implementation (5slower for 1.8, 2*slower for 1.9 although it could
be faster than inheritance and mixins in a far future, but this is not
really an issue here).
Now I do not really want to promote my packages here, I will not even
make the noise of putting uris here, those intersted can search for
Labrador and ruby-traits on Rubyforge. What I want is to encourage
people to go ahead, not accepting things as they are, forgetting of
inheritance and mixins sometimes and try out some different
approaches, not necessarily mine.
And all that simply because I feel that establishing is_a?
relationships does not really make much sense if we do not use them.
The polymorphic approach is not at all limited to the static
inheritance scheme, it is even much more ducktypier than that:). And
that is why I believe that using class and inheritance and mixins is
often convenient and very often not a problem at all, but it is maybe
more a tool than a concept in Ruby.
Pheww I hope I got some messages across if not sorry for the waste of
bandwith.
Cheers
Robert
–
http://ruby-smalltalk.blogspot.com/
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein
On May 29, 2008, at 3:37 AM, David A. Black wrote:
Duck typing, as a way of thinking, meshes nicely with Ruby, as a tool,
because of how Ruby objects are engineered: the only thing that you
can measure with certainty is what an object does when you send it a
message.
No, you cannot possibly measure with certainty what an object does
when you send it a message. The only thing you can measure is whether
it will throw a runtime error because it doesn’t implement a method
for the message.
You can ask it what its class is, what its ancestors are,
what methods it responds to, and so forth… but in the end, you hit
the singularity: the sending of the message.
However, an object’s class and ancestors determine what messages an
object responds to. That’s what they’re there for - to hold message
maps.
it stands
to reason that a language with objects whose types can change during
runtime would be well-served by a programming style that deals as
directly and economically as possible with precisely that condition.
Hmmm. Is it that objects change their type, or is it that variables do?
///ark
On May 29, 2008, at 1:18 AM, Bill K. wrote:
x.respond_to? :to_int
=> truex.to_int
=> 123
Good point.
///ark
On May 29, 2008, at 1:49 AM, F. Senault wrote:
Le 29 mai à 06:45, Eleanor McHugh a écrit :
Numeric may well mean “numeric” in some particular sense, but that is
only a subset of all objects which may have a valid numeric
representation. As I said, you’re applying a static typing mindset to
a place where it’s not necessary and whilst Ruby will let you do
that,
in the long term you’ll find yourself doing much more work with very
little (if any) gain in software robustness.
Man, I’m really not giving these replies the attention they deserve,
but I did want to mention one thing:
This has nothing to do with “static typing.” “Static typing” refers to
type checking being performed at compile-time instead of runtime. It
has nothing to do with interrogating an object’s class during the
execution of a program. If you think about it, the class of an object
is continually being interrogated at runtime, in order to dispatch a
given message to the right method.
///ark
On May 29, 2008, at 2:14 AM, David M. wrote:
I can say
quite categorically, that in OOP, classes are ways to generalize. You
generalize based on characteristics and behaviors. A class is not
simply a random collection of methods. It would be rather useless if
class was unrelated to category.I’m going to have to respectfully disagree here.
I’m not sure what you’re disagreeing with, here. That classes are
categories? If so, I could refer you to any number of the sources I
learned OOP from - except that I’ve given them all away by now.
If classes are not categories, what are they?
Unless you are going to have branching based on type – that is,
simple method
overloading (as in C++ and friends) – I don’t see as much point to
a rigid
type system.
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.
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.
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!”. So I think this whole discussion is about an edge case.
It boils down to: Why should I care whether I’m being passed a
number or
something which merely behaves like a number? Why should I care if
I’m being
passed a string or an array of characters?
Actually, I agree, in general, and this discussion has clarified the
concept for me.
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.
However, I still think using responds_to? to identify an object’s type
is risky. 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).
to build it out of a while loop:
data.each { |datum|
do_something_with datum
}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.
But if you do that, I don’t understand why you’re using Ruby. Again,
nothing
wrong with it – do whatever makes you happy, and maybe you’re right
and I’m
wrong. But I doubt I’ll ever understand it.
There is something wrong with it. It’s harder to read and more prone
to error.
Can you outline a few real-world examples, where it’s OK to get a
descendant
of Numeric, but not something which merely implements to_i or to_f?
The obvious case is an object that implements to_i in a noncongruent
way. For example, let’s say the number passed in is to be used as a
count. An IP address may respond to to_i, but it can’t possibly be
correct in this context.
True. And often the most straightforward and fundamental way to do
that is to call its #class method.Not really.
Firstly, #class doesn’t provide any way to be in multiple
categories. Ruby
doesn’t support multiple inheritance.
We’re not talking about multiple categories - just one. In all my
years of using MI in C++, I’ve very rarely, if ever, seen a class that
didn’t have a “dominant” base class. Most of the time MI is used for
mixing in. You might have a class, for example, that descends both
from Numeric and Observable, but obviously, its main category is
Numeric. In the case under discussion, I don’t think multiple
categories are relevant.
At any rate, even if you don’t think we should be using #class, you
can sure bet the language disagrees! We wouldn’t get very far without
it.
I was emailcommunicado for a day or so, so I’m trying to catch up and
I’m running out of steam, here. …
///ark
In article [email protected],
Mark W. [email protected] wrote:
it stands
to reason that a language with objects whose types can change during
runtime would be well-served by a programming style that deals as
directly and economically as possible with precisely that condition.Hmmm. Is it that objects change their type, or is it that variables do?
As far as I’m concerned objects do not have a type, only variables do.
It determines what objects they can reference based on a trait like
class, ancestor, interface. In Java.
So I’d say that Ruby doesn’t even have types. You can never know in
advance what methods the object in a certain variable might respond to.
And since message-maps are per-object, typed variables wouldn’t even
change that. Just like neither kind_of? nor .class === can help you.
responds_to? does help, but can return false negatives if the target
overrides missing_method.
Consequently the most economic style for a Ruby method would be to just
take whatever argument comes in and fire some messages. Deal with any
excpetions. And at critical points maybe check the resulting value for
tangible properties like > 0 or empty?.
On May 29, 2008, at 3:47 AM, Michael T. Richter wrote:
Classes are the unit of state.
Classes are the unit of access control.
Classes are the unit of functional dispatch.
These are simply the attributes of a type: a set of possible values
and a set of possible operations.
///ark
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs