On Wed, Mar 29, 2006 at 12:00:32AM +0900, [email protected] wrote:
} On Tue, 28 Mar 2006, Robert D. wrote:
} >and how can one modify a receiver without modifying its instance
variables,
}
} str = “hello”
} str.replace(“goodbye”)
}
} I’ve changed str without any instance variables being involved. Same
} with:
}
} array = [1,2,3]
} array.pop
}
} and so forth.
It’s a technicality. Consider strings. Their internals are under the
hood,
so you claim that no instance variables are involved. This is not
technically accurate. Object state happens to be held in C variables
rather
than Ruby variables (which are, of course, backed by C variables), but
they
are most certainly instance variables. Are you trolling or do you
actually
believe you are right?
It’s a technicality. Consider strings. Their internals are under the hood,
so you claim that no instance variables are involved. This is not
technically accurate. Object state happens to be held in C variables rather
than Ruby variables (which are, of course, backed by C variables), but they
are most certainly instance variables. Are you trolling or do you actually
believe you are right?
I’ve been using Usenet since 1990 and never trolled. I’m not going to
start now.
I’m talking about Ruby, not C. In Ruby, you can modify a receiver
without changing its instance variables – in fact, you can modify a
receiver that doesn’t have any instance variables.
On Tue, Mar 28, 2006 at 11:22:31PM +0900, Peter H. wrote:
} Michael U. wrote:
[…]
} >It would if you knew C++. This is actually one of the more useful
} >features of C++. If a method is declared ‘const’, the compiler
ensures
} >that it does not modify the instance variables of the object (unless
you
} >use really deep magic). This can be quite useful when debugging.
}
} I program in C++ (and Java and Perl) but fail to see how a feature
from
} a statically typed language would provide any benefit to a dynamic
} language such as Ruby. Without even trying to work out how you would
} hope to graft it on. I have never wanted for such a feature in Ruby
but
} I have wanted features from Ruby in other languages.
There are many valuable features that are orthogonal to whether typing
is
static or dynamic. One example is OO. The const-ness of an object is a
typing issue, but duck-typing is still typing. When I call a method on
an
object, I am asking it to respond to a particular message with a
particular
set of arguments (which are part of the definition of the message). If
it
doesn’t, it is not “a duck.” If I ask an object to respond to a
particular
message, and included in that message is an argument that is const, the
object is only “a duck” if it can accept and use that argument without
modifying it.
} >I hope the condescending tone here was an accident. You too don’t
know
} >everything (see above), and you too make mistakes (see above).
}
} I was cutting to the chase. I have read too many posts from people who
} have only read a couple of articles on Ruby and think that they can
fix
} by making it more like C++, C, Java, Python, Perl, Visual Basic or
} whatever they think they understand. Inexperienced programmers seem to
} have a love of languages with many arcane and complex rules and when
} they don’t find them they get all flustered and try and fix things
} rather than try and understand how we could possibly develop anything
} without them.
The original poster may not have a perfect grasp of English, and
therefore
his expression of his ideas was imperfect. Nonetheless, his suggestions
were interesting and could lead to worthwhile idioms, if not features,
in
Ruby. Your dismissiveness helps no one.
On Wed, Mar 29, 2006 at 12:56:25AM +0900, [email protected] wrote:
[…]
} I’m talking about Ruby, not C. In Ruby, you can modify a receiver
} without changing its instance variables – in fact, you can modify a
} receiver that doesn’t have any instance variables.
}
} irb(main):001:0> s = “”
} => “”
} irb(main):002:0> s.replace(“abc”)
} => “abc”
} irb(main):003:0> s.instance_variables
} => []
}
} The term “instance variable” has a specific and unambiguous meaning in
} Ruby.
I repeat, it’s a technicality. A string’s internal state is held in
variables tied to the particular instance. They are not visible to the
Ruby
runtime, however, so they are not listed in the array returned by the
object’s instance_variables method. Do you really believe that methods,
which modify those variables, do not change the instance variables
simply
because the runtime is unaware of the variables? No, I don’t think so.
You
are arguing a technicality.
You may be arguing this technicality because you think it is relevant to
plausible implementations of const objects, and you may be right.
Clearly,
any methods that are not entirely implemented in pure Ruby would have to
be
explicitly marked as const or not since their const-ness could not be
dicovered automatically. This is not unreasonable, however; extensions
are
special cases to begin with.
I’m working on a program that indexes semilarge amounts of data in
various ways. Now it can be argued that if I care about performance I
shouldn’t use ruby, but I do care and I am using. One of my classes
has a query method:
def query(q)
…
end
From a high level semantics point of view query is very much a read
only function. It takes a string, interprets it in certain ways, and
reports the results.
However, with how my application is used, successive queries tend to
be related. So, under the hood there is a great deal of caching going
on; various instance variables are being changed. It would be
extremely counter intuitive to the user if I had to name my routine
query!.
My point (which no doubt had been made) is that it is difficult for a
parser to determine the higher level semantics of a routine. This is
especially true in a language as dynamic as ruby.
} language such as Ruby. Without even trying to work out how you would
object is only “a duck” if it can accept and use that argument without
modifying it.
Fine. Firstly explain how having const methods in Ruby would enhance the
language, that is to say how is would help do something in Ruby easier
and safer than the current version of Ruby, then (for bonus points)
explain how it could be implemented. Just because a feature exists in
another language does not mean that it is /missing/ from Ruby. I like
abstract methods in Java but I do not think that they are missing from
Ruby and their absence has not caused me any problems. What makes a
language a good language in my book is not a feature list of every
conceivable paradigm but a clear underlying philosophy that is simple to
grasp, this means that a good language will probably not have some
features that are in other languages. Lua does not include integers!
Imagine that, a language without integers. We must fix that at once!!
Lets not fall into the trap of penis envy here. Ruby does not need a
whole bunch of features added to it just because some other language has
them.
The original poster may not have a perfect grasp of English, and therefore
his expression of his ideas was imperfect. Nonetheless, his suggestions
were interesting and could lead to worthwhile idioms, if not features, in
Ruby. Your dismissiveness helps no one.
The posters command of English was not an issue and even he did not use
it as an excuse but what he did not explain (and I believe that his
command of English is up to the task) is why these features were lacking
from Ruby. ‘Other languages have them’ is not good enough.
plausible implementations of const objects, and you may be right. Clearly,
any methods that are not entirely implemented in pure Ruby would have to be
explicitly marked as const or not since their const-ness could not be
dicovered automatically. This is not unreasonable, however; extensions are
special cases to begin with.
I don’t see any technicality in what David is saying. You might
want to try to re-cast your argument in terms that make sense
in Ruby.
A string in Ruby certainly has internal state, but it certainly
does not (in the usual case) have instance variables.
On Tue, Mar 28, 2006 at 11:51:05PM +0900, Peter H. wrote:
} Gregory S. wrote:
[…]
} >Have you programmed in C++? There is a great deal of value to the
idea
} >of const instances of objects which only allow const methods to be
} >called on them. I’m not claiming that Ruby should necessarily support
} >such a thing, but I can certainly understand the desire for it.
}
} I do program is C++ but, as I’ve said in another reply, I fail to see
how
} this is supposed to be of benefit in a dynamic language such as Ruby
and
} also how would you propose to implement it?
[…]
The simplest implementation is to override the send() method and list
non-const methods somewhere. In the send method, check whether the
object
is marked as const and throw an exception if a non-const method is
called.
There are more complicated implementations, but that’s the easiest one.
} >There is no reason to be insulting. It is not unreasonable to expect
[…]
} I was not being insulting, I honestly think that the poster does not
} understand the issues. To understand a language you have to learn to
use
} it, once you do you get passed such superficial issues, such as the
use
} of ! on the end of a method name, they tend to become forgotten like
the
} lack of a prefix / postfix increment / decrement operator that people
} coming from C++ and Java seem to stumble over as if it was a major
} issue. Sure Lisp has lots of brackets and you have to indent things in
} Python but once you learn the language these are no longer issues.
When
} people have problems with Lisp brackets, Python indents or Ruby !s
they
} haven’t even got as far as the syntax of the language let alone gained
} an understanding of the heart of the language. Therefore I tend to be
} abrupt with such people that then have the temerity to fix the
} problems that is nothing more than their lack of experience.
Only dead languages never change, and Ruby is emphatically not dead.
Pleasantly, Ruby is a language in which the community has some say. Matz
reads the mailing list (at least to some unknown extent; I’ve seen him
reply) and if a sufficiently compelling and clear argument for a
particular
feature is posted, perhaps he’ll consider it. I think you are also
confusing his mediocre English skills with a mediocre understanding of
programming languages.
On Wed, Mar 29, 2006 at 05:50:30PM +0900, Peter H. wrote:
[…]
} Fine, now say how this is supposed to be of benefit to Ruby. What does
} it make doing in Ruby easier and safer than the present way we go
about
} doing it?
[…]
} This is my point, there was no “sufficiently compelling and clear
} argument” given other than it is available in C++.
I don’t know that it is of great benefit to Ruby, honestly. I certainly
found it valuable in C++, but that had a lot to do with a need to
provide
libraries with as much in the way of machine-readable documentation
(e.g. I
promise I won’t delete this object you are passing me) as possible given
that I knew the consumers of the library wouldn’t read anything I wrote
about it.
There are certainly advantages to design-by-contract, of which const is
a
special case. I’d like to see some machine-readable guarantees of
preconditions and postconditions and invariants and the like in Ruby.
Such
guarantees are both debugging aids and optimization hints. For a
language
like Ruby, where many of its uses are quick scripts, an actual
requirement
to put such guarantees in one’s code would be a problem. Optional hints
and
assertions are easy, however.
In any language, including Ruby, it is possible to assert preconditions
and
postconditions. Invariants are somewhat more difficult without runtime
support. What makes a language truly support design-by-contract is that
these assertions mean something specific to the runtime beyond code to
be
executed. No, I can’t come up with a Ruby implementation off the cuff.
It is an interesting idea that someone could run with, however, and it
is
for that reason that I objected to your stifling dismissiveness. If you
look back at my posts, you will notice that I never defended const, or
enforcing any particular meaning for the ! method suffix. I regarded the
original poster’s ideas as interesting, and worth discussing.
The simplest implementation is to override the send() method and list
non-const methods somewhere. In the send method, check whether the object
is marked as const and throw an exception if a non-const method is called.
There are more complicated implementations, but that’s the easiest one.
Fine, now say how this is supposed to be of benefit to Ruby. What does
it make doing in Ruby easier and safer than the present way we go about
doing it?
} people have problems with Lisp brackets, Python indents or Ruby !s they
confusing his mediocre English skills with a mediocre understanding of
programming languages.
This is my point, there was no “sufficiently compelling and clear
argument” given other than it is available in C++.
} irb(main):001:0> s = “”
variables tied to the particular instance. They are not visible to the Ruby
that that’s not what the OP meant, but in that case it’s a good chance
for him to learn the customary use of the terminology.
Obviously something changes when you change the contents of a string
or array. But calling it, without qualification, an “instance
variable” of the object is almost certainly a recipe for unclarity and
confusion down the road.
If I can just chime in here, I agree with what I think is David’s point
that instance variables and ‘state’ are separate (though often
overlapping) things. Should this be a bang method?:
class PoolStr < String
def suffixes @suffixes ||= find_suffixes
end
end
Here, ‘suffixes’ uses an instance variable to cache the result, but I
wouldn’t say this modifies the object’s state as far as the user of the
API is concerned, since were it removed the class would work exactly the
same, just more slowly. I think the distinction is between internal and
external state (both of which may or may not be maintained in instance
variables) - exactly what constitutes which of those is probably down to
the guy who codes it up.
} irb(main):003:0> s.instance_variables
because the runtime is unaware of the variables? No, I don’t think so. You
are arguing a technicality.
I’m not arguing at all. Someone asked a question about instance
variables (meaning Ruby instance variables, I assumed), and I answered
it. I assume, by default, that questions about Ruby are questions
about Ruby itself, rather than the C implementation. It’s possible
that that’s not what the OP meant, but in that case it’s a good chance
for him to learn the customary use of the terminology.
Obviously something changes when you change the contents of a string
or array. But calling it, without qualification, an “instance
variable” of the object is almost certainly a recipe for unclarity and
confusion down the road.
