Forum: Ruby Why do some methods names which replace the content in place

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Eric B. (Guest)
on 2006-03-27 04:06
(Received via mailing list)
Hi,

I was wandering why some ruby methods which replaces the contents of its
variable doesn't follow the rules which say that when the method name
has a "!" symbol at the end, it means that its contents will be replace
in place. For example:

Array#replace instead of Array#replace!
Array#clear instead of Array#clear!
...

Is it because the name really mean what it mean? Maybe am I all wrong?

Thanks,
Timothy H. (Guest)
on 2006-03-27 04:19
(Received via mailing list)
Eric B. wrote:
>
> Is it because the name really mean what it mean? Maybe am I all wrong?
>
> Thanks,
>
>
>
Using a ! to mean "destructive" is not a hard-and-fast rule. Usually
(but not always) it's used when there are a pair of methods with the
same name, one destructive and one not. If there is only one method with
that name, such as the two examples you give, then adding the ! is not
particularly useful. But there are always exceptions.
Hal F. (Guest)
on 2006-03-27 04:39
(Received via mailing list)
Tim H. wrote:
> Eric B. wrote:
>>
>> Is it because the name really mean what it mean? Maybe am I all wrong?
>>
> Using a ! to mean "destructive" is not a hard-and-fast rule. Usually
> (but not always) it's used when there are a pair of methods with the
> same name, one destructive and one not. If there is only one method with
> that name, such as the two examples you give, then adding the ! is not
> particularly useful. But there are always exceptions.
>

The ! doesn't even mean "destructive" really. It means "dangerous" or
"caution required." In the core, there is only one instance of a non-
destructive bang method, but in my own code, I do like to make the
distinction more.


Hal
unknown (Guest)
on 2006-03-27 05:44
(Received via mailing list)
Hi --

On Mon, 27 Mar 2006, Eric B. wrote:

>
> Is it because the name really mean what it mean? Maybe am I all wrong?

See Tim and Hal's responses.  A further reflection on it: In cases
where it would make no sense for there to be a non-"dangerous" version
of the method, there's no need for the method/method! pair.  In the
case of #replace, it's hard to imagine what it would mean to replace
the contents of an array without changing it.  And in the case of
clear, a non-destructive version would just be the same as [] :-)

So yes, it's because the name already implies the whole operation.


David

--
David A. Black (removed_email_address@domain.invalid)
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
James G. (Guest)
on 2006-03-27 05:52
(Received via mailing list)
On Mar 26, 2006, at 6:39 PM, Hal F. wrote:

> In the core, there is only one instance of a non-
> destructive bang method...

Just curious, what is this method?

Thanks.

James Edward G. II
Hal F. (Guest)
on 2006-03-27 06:01
(Received via mailing list)
James Edward G. II wrote:
> On Mar 26, 2006, at 6:39 PM, Hal F. wrote:
>
>> In the core, there is only one instance of a non-
>> destructive bang method...
>
>
> Just curious, what is this method?

exit!

:)

H
unknown (Guest)
on 2006-03-28 01:53
(Received via mailing list)
It would make sense to have a pair replace and replace!.
For example for Strings, it could be imagined such methods myreplace
and myreplace!:
a="abcd"
b=a.myreplace('a', 'b')
puts(a) # => "abcd"
puts(b) # => "bbcd"
b=a.myreplace!('a', 'c')
puts(a) # => "cbcd"
puts(b) # => "cbcd"
unknown (Guest)
on 2006-03-28 02:34
(Received via mailing list)
Hi --

On Tue, 28 Mar 2006, removed_email_address@domain.invalid wrote:

> It would make sense to have a pair replace and replace!.
> For example for Strings, it could be imagined such methods myreplace
> and myreplace!:
> a="abcd"
> b=a.myreplace('a', 'b')
> puts(a) # => "abcd"
> puts(b) # => "bbcd"
> b=a.myreplace!('a', 'c')
> puts(a) # => "cbcd"
> puts(b) # => "cbcd"

That's not what replace does, though.  See sub and sub!


David

--
David A. Black (removed_email_address@domain.invalid)
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
Robert D. (Guest)
on 2006-03-28 13:07
(Received via mailing list)
On 3/27/06, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> > in place. For example:
> case of #replace, it's hard to imagine what it would mean to replace
> 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
>
>
I am in a revolutionary mood today.
So I will put it to extremes:

It is a shame that methods can be defined in ruby, that do not end in
"!"
and still can modify instance variables of the receiver! (pun intended)

Honestely I think that would be a nice thing to have and I never even
thaught about it, I really appreciate Eric's view!

Cheers
Robert

BTW
If there are always exceptions it follows that there must exist at least
one
exception to that rule :))

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein
unknown (Guest)
on 2006-03-28 16:21
(Received via mailing list)
Hi --

On Tue, 28 Mar 2006, Robert D. wrote:

> I am in a revolutionary mood today.
> So I will put it to extremes:
>
> It is a shame that methods can be defined in ruby, that do not end in "!"
> and still can modify instance variables of the receiver! (pun intended)

I'm all for revolutionary moods, but I'm afraid that makes no sense at
all :-)

Instance variables are the object's business.  When you call a method,
you shouldn't even have to know whether instance variables are
involved.  Also, ! means "dangerous", and there's nothing inherently
dangerous about methods that use instance variables.


David

--
David A. Black (removed_email_address@domain.invalid)
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
Robert D. (Guest)
on 2006-03-28 16:51
(Received via mailing list)
On 3/28/06, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> > and still can modify instance variables of the receiver! (pun intended)
>
> I'm all for revolutionary moods, but I'm afraid that makes no sense at
> all :-)


Makes a lot of sense to me (seriously!!!)

Instance variables are the object's business.  When you call a method,
> you shouldn't even have to know whether instance variables are
> involved.  Also, ! means "dangerous", and there's nothing inherently


Please define "dangerous", I do not have the most remote idea what might
be
dangerous, apart
of modifying state, which is "modifying instance variable".


dangerous about methods that use instance variables.
>
>
> David


I do not want to change Ruby, but the basic idea to have a clear
syntactic
definition of what is "read only" access and what is "write" access
seems
very appealing to me.

Please try to get out of the Ruby paradigm for that *theoretical*
discussion.
So tell my why it is a bad idea, if you think it is a bad idea.
It does not make sense, is not a reason, BTW ;)
I will tell you why it is a good idea.


* The first and most important reason is a practical one
How great for debugging and maintenance of code, you will never have to
examine methods not ending with ! if you are searching for the reason of
some strange value.
Look at a C++ developper, she will never have to look into methods
declared
with "const", and
do you really think Ruby should be outclassed by C++?
And it would be much better than in C++ because the information is
conveyed
at declaration and at usage.

* The second reason is that this is only the surface of the iceberg
It will be a revolutonary concept, think about classes.
Only classes with names ending in "!" can be subclassed.
Or classes not ending with "!" will become unmodifiable as Java::String
or
python::string
There are for sure much more ideas, and much better ideas, that will
spring
into the mind of
much more informed people than your humble servant.

* The third reason is that I always felt unsure of !,? and = at the end
of
method names
Try to use this method
class Bad; def a=; puts "very bad"; end; end
So "!", "?" do not have the same kind of impact than "=", not too much
orthogonal, is it?

Enforcement (late but never theless ) of "=" is already "rubyish", why
should "!" (or "?", please see below) not be?

* Other, much less important reasons, include ease for tools, analyzers
and
just beacause it would make the language more expressive.
I always found there should be a class Boolean in Ruby with
class Boolean < Object...
class TrueClass < Boolean ...
class FalseClass < Boolean

than we could e.g. assure that
a method ending in ? would return a Boolean.

Of course other syntactic measures could be taken, but ! just seems fine
for
right now.

Maybe nobody wants this in Ruby, still I think it is a good idea to
think
about concepts like this.

Cheers
Robert

--
> David A. Black (removed_email_address@domain.invalid)
> 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
>
>


--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein
unknown (Guest)
on 2006-03-28 17:03
(Received via mailing list)
Hi --

On Tue, 28 Mar 2006, Robert D. wrote:

>> "!"
>> involved.  Also, ! means "dangerous", and there's nothing inherently
>
>
> Please define "dangerous", I do not have the most remote idea what might be
> dangerous, apart
> of modifying state, which is "modifying instance variable".

A lot of ! methods on container objects (including strings) modify
their receivers.  Instance variables aren't involved.  These are cases
where it might matter to the caller whether the change is permanent or
not.  With instance variables, it's not the caller's business.


David

--
David A. Black (removed_email_address@domain.invalid)
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
Peter H. (Guest)
on 2006-03-28 17:23
(Received via mailing list)
Robert D. wrote:
> Please define "dangerous", I do not have the most remote idea what might be
> dangerous, apart of modifying state, which is "modifying instance variable".
>
Dangerous is any function that modifies the caller. Thus
fred.gsub(/[aeiou]/, '*') does not modify fred, it returns a new object
that is the result of gsub(/[aeiou]/, '*') being applied to fred.
However fred.gsub!(/[aeiou]/, '*') both returns a new object that is the
result of gsub(/[aeiou]/, '*') being applied to fred *AND* modifies
fred. Most methods in Rudy do not modify the caller but return a new
object. So anything that behaves differently / unexpectedly is
dangerous. In Ruby most (if not all) the classes that have ! methods
also have non ! version that does not alter the caller. This has been
explained before but I can't remember which id the thread starts at. I
expect someone will be able to point this out.
> I do not want to change Ruby, but the basic idea to have a clear syntactic
> definition of what is "read only" access and what is "write" access  seems
> very appealing to me.
>
>
Methods have nothing to do with "read only" and "write" access. I don't
know where you got this concept from but it is clearly confusing you,
discard the concept, it is hindering your understanding of what Ruby is
actually doing.

>
This doesn't make the slightest bit of sense to me.
> * The second reason is that this is only the surface of the iceberg
> It will be a revolutonary concept, think about classes.
> Only classes with names ending in "!" can be subclassed.
> Or classes not ending with "!" will become unmodifiable as Java::String or
> python::string
> There are for sure much more ideas, and much better ideas, that will spring
> into the mind of
> much more informed people than your humble servant.
>
>
Ruby is a dynamic language, thus you can change classes. In fact is it a
very powerful concept (revolutionary even). If you want B&D then go
ahead and use Java (by the way you can modify unmodifiable Java Strings)
but the reason that people like Ruby is that they can get things done
without the language getting in the way.
>
I was going to answer this and your other points but frankly I get the
impression that you don't know enough about programming to understand
the answers. A lot of the converts to Ruby are programmers with many
years experience who found, like myself, that they could get the job
done in Ruby much easier than the various languages that they had been
using for years. That was the revolutionary concept and you seem to have
missed it completely.
Gregory S. (Guest)
on 2006-03-28 17:54
(Received via mailing list)
On Tue, Mar 28, 2006 at 10:23:21PM +0900, Peter H. wrote:
} Robert D. wrote:
[...]
} Methods have nothing to do with "read only" and "write" access. I
don't
} know where you got this concept from but it is clearly confusing you,
} discard the concept, it is hindering your understanding of what Ruby
is
} actually doing.
}
} >* The first and most important reason is a practical one How great
for
} >debugging and maintenance of code, you will never have to examine
} >methods not ending with ! if you are searching for the reason of some
} >strange value. Look at a C++ developper, she will never have to look
} >into methods declared with "const", and do you really think Ruby
should
} >be outclassed by C++? And it would be much better than in C++ because
} >the information is conveyed at declaration and at usage.
}
} This doesn't make the slightest bit of sense to me.

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.

} >* The second reason is that this is only the surface of the iceberg
It
} >will be a revolutonary concept, think about classes. Only classes
with
} >names ending in "!" can be subclassed. Or classes not ending with "!"
} >will become unmodifiable as Java::String or python::string There are
for
} >sure much more ideas, and much better ideas, that will spring into
the
} >mind of much more informed people than your humble servant.
}
} Ruby is a dynamic language, thus you can change classes. In fact is it
a
} very powerful concept (revolutionary even). If you want B&D then go
ahead
} and use Java (by the way you can modify unmodifiable Java Strings) but
} the reason that people like Ruby is that they can get things done
without
} the language getting in the way.

I'm inclined to agree with this. In addition, if you *really* need a
class
that can't be changed you can freeze it; preventing subclassing can be
done
by making the class's inherited method throw an exception. It's
possible,
but probably undesirable. Note that there is absolutely nothing
revolutionary about Ruby, except possibly some of the software being
written in it. Ruby is an excellent implementation of a lot of good
programming language ideas (reflection/introspection, message sending,
anonymous blocks, OOP, mixins, dynamic typing, etc.), but there is
nothing
genuinely new about it.

} >* The third reason is that I always felt unsure of !,? and = at the
end
} >of method names Try to use this method class Bad; def a=; puts "very
} >bad"; end; end So "!", "?" do not have the same kind of impact than
"=",
} >not too much orthogonal, is it?
} >
} >Enforcement (late but never theless ) of "=" is already "rubyish",
why
} >should "!" (or "?", please see below) not be?
}
} I was going to answer this and your other points but frankly I get the
} impression that you don't know enough about programming to understand
the
} answers. A lot of the converts to Ruby are programmers with many years
} experience who found, like myself, that they could get the job done in
} Ruby much easier than the various languages that they had been using
for
} years. That was the revolutionary concept and you seem to have missed
it
} completely.

There is no reason to be insulting. It is not unreasonable to expect
various non-alphanumeric characters at the end of a method name to mean
something to the parser, particularly when one of them (equals) actually
does. Furthermore, the question mark has a pretty clear semantic
meaning,
and almost all ruby code adheres to the convention well.

The bang (!), however, is used inconsistently. Its primary value seems
to
be distinguishing between methods that produce the same result, but the
one
without the bang produces the result in a returned copy whereas the
version
with the bang modifies the receiver to take on the resulting value
before
returning itself. Other uses muddy the waters, including the distinction
between save() and save!() in ActiveRecord models. So we call it
"dangerous" and define this vaguely to mean whatever the API author
considers dangerous. I consider the availability of the bang as an
allowed
character in a method name a noble, but largely failed, experiment.

--Greg
Michael U. (Guest)
on 2006-03-28 17:57
(Received via mailing list)
Peter H. wrote:

> that is the result of gsub(/[aeiou]/, '*') being applied to fred.
> However fred.gsub!(/[aeiou]/, '*') both returns a new object that is the
> result of gsub(/[aeiou]/, '*') being applied to fred *AND* modifies
> fred.

You are mistaken. Consider

a = [1, 2, 3]
a.delete(3)
a               # => [1, 2]


>> conveyed
>> at declaration and at usage.
>>
>>
>
> This doesn't make the slightest bit of sense to me.

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.

>> much more informed people than your humble servant.
>>
>>
>
> Ruby is a dynamic language, thus you can change classes. In fact is it a
> very powerful concept (revolutionary even). If you want B&D then go
> ahead and use Java (by the way you can modify unmodifiable Java Strings)
> but the reason that people like Ruby is that they can get things done
> without the language getting in the way.

100% agreed.

>> should "!" (or "?", please see below) not be?
>
>

I hope the condescending tone here was an accident. You too don't know
everything (see above), and you too make mistakes (see above).


Regards,

Michael

--
Michael U.
R&D Team
ISIS Information Systems Austria
tel: +43 2236 27551-219, fax: +43 2236 21081
e-mail: removed_email_address@domain.invalid
Visit our Website: www.isis-papyrus.com
Peter H. (Guest)
on 2006-03-28 18:22
(Received via mailing list)
Michael U. wrote:
>> Dangerous is any function that modifies the caller. Thus
> a               # => [1, 2]
>
I did not say that all methods that changed their caller had a !. I was
only explaining what the dangerous meant in reference to those classes
that had both a ! and non ! version of the method. Ruby is a little
inconsistent but the ! is a syntactic - not a rule, not enforced in any
way what so ever - convention (along with the ?) to make things clear
where they might be ambiguous. There are plenty of methods that alter
the caller but for gsub there are two versions of the same method and
the ! is there to point out which one is dangerous.
> 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.

> 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.
Robert D. (Guest)
on 2006-03-28 18:48
(Received via mailing list)
I am really sorry, this got way out of control.
I do have the impression that nobody understands anybody.
That is a pitty there were so nice concepts to be discussed, but I
really
feel that this discussion is not  going well.

Maybe another time :(


Just some clarifications

of course I find the "const" method of C++ a great thing, sorry if it
did
not come over
and how can one modify a receiver without modifying its instance
variables,
there is nowhere to go if we are caught by missunderstandings like this
one.
I am kind of %r{[sm]ad} about this, but that is *my* problem, you are
all
nice guys, that's why I bail out of this, it is too close too my heart
and I
cannot make myself understood.

Regards and Regrets

Robert
Peter H. (Guest)
on 2006-03-28 18:51
(Received via mailing list)
Gregory S. wrote:
> } >methods not ending with ! if you are searching for the reason of some
> 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?
> } answers. A lot of the converts to Ruby are programmers with many years
>
I always though of the ! as being a way of not having to come up with
yet another name for the same method. Image you have gsub and decide to
create the dangerous version, what do you call it that is easy to
remember, that wont be confused with gsub but will be associated with
gsub and can be applied to all similar dangerous versions. Sticking ! on
the end seems to be the sensible solution but I would not advocate
adding it to pop, delete and shift. There would be !s all over the place
which would make the code harder to read and there isn't a non dangerous
version of pop, delete and shift anyway.

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.
unknown (Guest)
on 2006-03-28 19:00
(Received via mailing list)
Hi --

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.


David

--
David A. Black (removed_email_address@domain.invalid)
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
unknown (Guest)
on 2006-03-28 19:44
(Received via mailing list)
> 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.

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! ;)
Gregory S. (Guest)
on 2006-03-28 19:50
(Received via mailing list)
On Wed, Mar 29, 2006 at 12:00:32AM +0900, removed_email_address@domain.invalid 
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?

} David
--Greg
unknown (Guest)
on 2006-03-28 19:56
(Received via mailing list)
Hi --

On Wed, 29 Mar 2006, Gregory S. wrote:

> }   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 (removed_email_address@domain.invalid)
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 S. (Guest)
on 2006-03-28 20:08
(Received via mailing list)
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.

--Greg
Peter H. (Guest)
on 2006-03-28 20:14
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> 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 S. (Guest)
on 2006-03-28 20:19
(Received via mailing list)
On Wed, Mar 29, 2006 at 12:56:25AM +0900, removed_email_address@domain.invalid 
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.

} David
--Greg
Chris A. (Guest)
on 2006-03-28 20:20
(Received via mailing list)
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 H. (Guest)
on 2006-03-28 20:37
(Received via mailing list)
Gregory S. wrote:
> } 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.
Hal F. (Guest)
on 2006-03-28 20:41
(Received via mailing list)
Gregory S. wrote:
> 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 S. (Guest)
on 2006-03-28 21:38
(Received via mailing list)
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.

--Greg
Peter H. (Guest)
on 2006-03-29 12:50
(Received via mailing list)
Gregory S. wrote:
> } 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?

> } 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++.
Gregory S. (Guest)
on 2006-03-29 16:42
(Received via mailing list)
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.

--Greg
unknown (Guest)
on 2006-03-29 16:52
(Received via mailing list)
Hi --

On Wed, 29 Mar 2006, Gregory S. wrote:

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


David

--
David A. Black (removed_email_address@domain.invalid)
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 B. (Guest)
on 2006-03-29 18:39
(Received via mailing list)
On Wed, 2006-03-29 at 21:48 +0900, removed_email_address@domain.invalid wrote:
> > } 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.
This topic is locked and can not be replied to.