Why do some methods names which replace the content in place doesn't have the "!" sign?

[dblack]

Hi --

} >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?

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.

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.


David

--
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black

 

[Gregory Seidman]

[...]
} >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.

--Greg

 

[Peter Hickman]

Then as participants here, it's our job to helpfully explain to
these folks, as best we can, how their suggestion may actually
not be a fix at all.

Geek points *will* be deducted for discourteousness!

Mea culpa

 

[Gregory Seidman]

]
} 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.

} David
--Greg

 

[Chris Alfeld]

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.

c.

 

[Peter Hickman]

[...]
} >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.

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.

 

[Hal Fulton]

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 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.


Hal

 

[Gregory Seidman]

[...]
} >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.

--Greg

 

[Peter Hickman]

[...]
} >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.

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?

} >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.

This is my point, there was no "sufficiently compelling and clear
argument" given other than it is available in C++.

 

[Gregory Seidman]

]
} 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.

--Greg

 

[dblack]

Hi --

]
} 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.

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.


David

--
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black

 

[Ross Bamford]

Hi --

]
} 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.

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.

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.