I don’t know what you mean by (ir)reversible, but the point is that
it’s meaningless to talk about arbitrary objects being able to do
arbitrary things. For example (and Guy has already given some),
String#strip removes whitespace. What would it mean to remove
whitespace from a Hash or a Fixnum or a MyThing? And more to the
point, what would happen if
I don’t mean: “Could such objects have some method called ‘strip’
which made sense for them?” because that’s not what you’re suggesting.
What you’re suggesting is that String#strip, Array#join, Thread#join,
IO#readlines, Regexp.escape, MyThing#some_method, and every other
method written for any purpose in Ruby should, without change or
adaptation, work for any Ruby object.
By the same reasoning, Ruby is suggesting that any module makes sense in
any class/object, because you can include a module in any class you’d
like. With freedom comes the possibility of doing something wrong, but
that doesn’t make freedom wrong, now does it?
There’s a difference between freedom and a free-for-all or chaos. In
the case of module inclusion, of course you can do things that don’t
work:
module M
def x; strip; end
end
class C
include M
end
C.new.x # undefined method strip
but you’ve got a mechanism – a language design – in place which
handles errors. (And of course there’s much more to that design.) If
you simply cut-and-paste methods (including core methods) from one
object to another, you’re bypassing this.
On Wednesday 17 December 2003 03:06 pm, David A. Black wrote:
> I don’t know what you mean by (ir)reversible, but the point is that
> it’s meaningless to talk about arbitrary objects being able to do
> arbitrary things. For example (and Guy has already given some),
> String#strip removes whitespace. What would it mean to remove
> whitespace from a Hash or a Fixnum or a MyThing? And more to the
> point, what would happen if
···
On Wed, 17 Dec 2003, T. Onoma wrote:
It is not meaningless. It is not arbitrary. Programmer’s do not just blow
their nose and snotty code comes out. Your extreme over simplification has no
bearing.
Let’s see a real example, then. I must be simple, but every case I can
think of is probably something you would call an extreme over
simplification.
> I don’t mean: "Could such objects have some method called ‘strip’
> which made sense for them?" because that’s not what you’re suggesting.
> What you’re suggesting is that String#strip, Array#join, Thread#join,
> IO#readlines, Regexp.escape, MyThing#some_method, and every other
> method written for any purpose in Ruby should, without change or
> adaptation, work for any Ruby object.
No, that is not being said. What is being said: if the shoe fits, wear it.
Hmm… sounds like a bad work I know: *uck
It all about the Dynamics, baby! Let the Static go.
I think you’re preaching to the choir here, though I’m not really sure I
understand what you’re trying to say with all of these colorful
colloquialisms.
I never said that. The analogy was including a mixin (seen as a collection
of methods) in different classes and including a single method in
different classes. I never compared a module with a class.
But I see what you mean. The methods in a mixin should be designed to work
in multiple classes, and methods in a class shouldn’t (necessarily). True,
but there’s a “should” on both sides. My point was the “should”.
What you seem to be saying is that no method in any class could possibly
ever work in any other class.
There’s a difference between freedom and a free-for-all or chaos. In
the case of module inclusion, of course you can do things that don’t
work:
module M
def x; strip; end
end
class C
include M
end
C.new.x # undefined method strip
but you’ve got a mechanism – a language design – in place which
handles errors. (And of course there’s much more to that design.) If
you simply cut-and-paste methods (including core methods) from one
object to another, you’re bypassing this.
Yes, agreed. But we want to implement a higher level language mechanism,
comparable to what modules do, but to do that we need to be able to move
methods.
And moving core methods (I assume you mean those implemented in the C
core) is indeed likely to give big problems. I haven’t considered that
yet. Even if Ruby would report an error if we tried to move a core method,
it would break our idea.
He’s talking about the methods in the module that you include in the class.
You know, like Enumerable’s. What difference does it make if it’s one lone
method or a whole bunch stuck in a namespace?
And BTW, last night I figured out how to do what I wanted by this very means.
I stuck one method in a module and moved the module around. But it turns out
the Ruby is again limited in this regard, b/c including modules in a class
actually has no effect on previously created objects of that class. To quote
matz:
“This is part of weakness of Ruby’s module system.
Including module into another module does not affect already
created instance/class/module.”
···
On Wednesday 17 December 2003 03:32 pm, ts wrote:
By the same reasoning, Ruby is suggesting that any module makes sense in
before trying to change ruby, try first to understand it.
Before we start calling each other names, I need a clarification. I can do
this in Ruby:
class A
end
class B < A
def m
end
end
class A
def m
end
end
Where twice represents the same bit of Ruby code. Nobody can
keep me from doing the above. If I understand correctly, Ruby doesn’t
allow the method to be copied from B to A, only from A to B. Now the
reason you say that Ruby’s test is correct, and it rightfully prevents us
from copying a method from B to A, is that because the above Ruby code
doesn’t make sense, or because Ruby somehow internally fixes method m for
use in B such that it is no longer fit to be used in A? Or rephrased, is
it because moving the code is wrong at the Ruby level, or at the
underlying implementation level?
“Ruby somehow internally fixes method m for use in B such that it is no longer
fit to be used in A” – This much is certain as has been demonstrated.
Although I do not know to what extent it does so.
As for being wrong at the Ruby level, I am willing to accept that. As David
pointed out, by your own suggestion, modules are intended for this use. It is
in fact possible to make an annonyomous module, add a method to it, and add
the module to any class. So there is a perfectly good mechinism. The
weakness, as matz pointed out, is that it is not a Dynamic inclusion.
But I do wonder, if one can do this using module containers, how much of a
stretch is it to allow the same thing on a method-by-method basis. Indeed one
could be quite “tricky” and give every method it’s own module.
···
On Wednesday 17 December 2003 04:17 pm, Peter wrote:
before trying to change ruby, try first to understand it.
Before we start calling each other names, I need a clarification. I can do
this in Ruby:
class A
end
class B < A
def m
end
end
class A
def m
end
end
Where twice represents the same bit of Ruby code. Nobody can
keep me from doing the above. If I understand correctly, Ruby doesn’t
allow the method to be copied from B to A, only from A to B. Now the
reason you say that Ruby’s test is correct, and it rightfully prevents us
from copying a method from B to A, is that because the above Ruby code
doesn’t make sense, or because Ruby somehow internally fixes method m for
use in B such that it is no longer fit to be used in A? Or rephrased, is
it because moving the code is wrong at the Ruby level, or at the
underlying implementation level?
Where twice represents the same bit of Ruby code. Nobody can
keep me from doing the above. If I understand correctly, Ruby doesn’t
allow the method to be copied from B to A, only from A to B. Now the
reason you say that Ruby’s test is correct, and it rightfully prevents us
from copying a method from B to A, is that because the above Ruby code
doesn’t make sense, or because Ruby somehow internally fixes method m for
use in B such that it is no longer fit to be used in A? Or rephrased, is
it because moving the code is wrong at the Ruby level, or at the
underlying implementation level?
Moving code is dangerous sometimes at C level. And I didn’t think it
is worth the cost of detecting whether moving is safe or not.
First of all what represents a core function? Every method that I know of can
be redefined. Even if it means the whole shebang comes to a scretching halt.
It’s the old adage of shotting one’s self in the foot. No one’s asking for
the world here. We simply wish to teach Ruby new tricks IN RUBY. If we find a
place in which this CAN’T be done then there’s a good chance that it’s a
potential stepping stone for improving Ruby in the future.
Granted, if there are already better ways to do something, then learning the
proper way is first and foremost. But when such means run dry, as has occured
here, it is not a question of learning Ruby first. Obviosuly if that was the
problem someone else would have already suggested a REAL SOLUTION rather then
simply saying: “what the heck you want to do that craziness for!”
We have come to you with an honest problem. It is for us to decide what we
wish to do with it. If you can show us another way, we would be greatly
appriciative. But if you can’t, it is assumptive and discourteous to suggest
that we have no need or knowledge of what we are really doing.
Thus pointing out someone’s own admittance that they have not considered
something should not be an invite for childish demonstratives of “told you
so”. This is not a contest of ego, but an honest exploration of possibility,
asking rather for constructive responses.
···
On Wednesday 17 December 2003 04:30 pm, ts wrote:
Before we start calling each other names, I need a clarification. I can
do P> this in Ruby:
try first to resolve this
And moving core methods (I assume you mean those implemented in the C
core) is indeed likely to give big problems. I haven’t considered that
^^^^^^^^^^^^^^^^^^^^^^^^^
yet. Even if Ruby would report an error if we tried to move a core
method, ^^^
it would break our idea.
