 |
|
| Computers Forum Index » Computer Languages (Ruby) » In-place parameter modification... |
|
Page 1 of 1 |
|
| Author |
Message |
| Dave Anderson... |
 Posted: Sat Oct 31, 2009 3:38 am |
|
|
|
Guest
|
Native to ruby are several methods that change passed-in parameters
in-place, such as chomp!(somestring). But I don't see any info on
creating these things myself. Is it possible to write methods that
change parameters this way?
--
Posted via http://www.ruby-forum.com/. |
|
|
| Back to top |
|
|
|
| Judson Lester... |
| Posted: Sat Oct 31, 2009 4:25 am |
|
|
|
Guest
|
[Note: parts of this message were removed to make it a legal post.]
Actually, chomp!(string) doesn't modify string, it modifies $_ (which, if I
recall correctly, is set by the -n and -p switches to ruby).
String#chomp! modifies the recipient.
Finally: ruby is a pass-by-reference language, so if you actually do make
changes the parameters of a method, the callers variables will change as
well. For instance:
def make_bacon(string)
string.replace "Chunky bacon."
end
hi = "hello"
make_bacon(hi)
hi #=> "Chunky bacon."
Judson
On Fri, Oct 30, 2009 at 4:38 PM, Dave Anderson <anderson at (no spam) crocker.com> wrote:
Quote: Native to ruby are several methods that change passed-in parameters
in-place, such as chomp!(somestring). But I don't see any info on
creating these things myself. Is it possible to write methods that
change parameters this way?
--
Posted via http://www.ruby-forum.com/.
|
|
|
| Back to top |
|
|
|
| Dave Anderson... |
| Posted: Sun Nov 01, 2009 1:50 am |
|
|
|
Guest
|
Rick Denatale wrote:
...
Quote: Objects are instances of classes, and typically have state, in some
cases like Fixnums the only state is really the object's identity, and
such objects are immutable, if two such objects have different state,
then they MUST be different objects. There is only one 1 object and
one 5 object. Symbols are similar in that there is only one instance
of symbol with a particular value.
Thanks for the fascinating and valuable insights, Rick. I didn't realize
what a can of worms I was opening here. And it's nice to know that
someone here remembers Fortran II, although that might make you a good
candidate for a Men-In-Black neurolizer.  As an old hand at C++, this
variable/value/type stuff is a very worthwhile lesson.
One practical thing I can draw out of this is the difference between
these two functions:
def X_1( str )
str[0] = 'X'
end
def X_2( str )
str = 'X' + str[ 1..-1 ]
end
The X_1 function alters the passed-in object in place, while the X_2
function modifies a local copy. I don't recall reading this in the
literature anywhere.
--
Posted via http://www.ruby-forum.com/. |
|
|
| Back to top |
|
|
|
| Jordi Bunster... |
| Posted: Sun Nov 01, 2009 3:30 am |
|
|
|
Guest
|
On Oct 31, 2009, at 1:03 PM, David A. Black wrote:
Quote: I don't think "replace" has any generalizable semantics. You can't
replace 2 with 3, for example (fortunately 
You could just memcpy a to b (as long as their classes are eql?). If
for a given object it doesn't make sense, like for singleton ones,
then you don't allow it.
I wonder if they would take a patch. Is not as if Ruby doesn't already
have a ton of edge cases anyway.
Quote: I also wonder why "replace" isn't called "replace!" :)
The !/non-! methods come in pairs. The ! one is the "dangerous" one --
that is, the one that probably has side-effects, special-case
semantics, ...
Ok, that makes sense now.
--
Jordi |
|
|
| Back to top |
|
|
|
| 7stud --... |
| Posted: Sun Nov 01, 2009 4:13 am |
|
|
|
Guest
|
Dave Anderson wrote:
Quote: Rick Denatale wrote:
...
Objects are instances of classes, and typically have state, in some
cases like Fixnums the only state is really the object's identity, and
such objects are immutable, if two such objects have different state,
then they MUST be different objects. There is only one 1 object and
one 5 object. Symbols are similar in that there is only one instance
of symbol with a particular value.
Thanks for the fascinating and valuable insights, Rick. I didn't realize
what a can of worms I was opening here. And it's nice to know that
someone here remembers Fortran II, although that might make you a good
candidate for a Men-In-Black neurolizer. As an old hand at C++, this
variable/value/type stuff is a very worthwhile lesson.
One practical thing I can draw out of this is the difference between
these two functions:
def X_1( str )
str[0] = 'X'
end
def X_2( str )
str = 'X' + str[ 1..-1 ]
end
The X_1 function alters the passed-in object in place,
Remember that in ruby "[]=" is the name of a method:
And a method can be programmed to alter the original string and return
it; or it can create a new string that is a copy of the original and
return the altered copy.
Quote: I don't recall reading this in the literature anywhere.
$ri String#[]=
------------------------------------------------------------- String#[]=
str[fixnum] = fixnum
str[fixnum] = new_str
str[fixnum, fixnum] = new_str
str[range] = aString
str[regexp] = new_str
str[regexp, fixnum] = new_str
str[other_str] = new_str
------------------------------------------------------------------------
Element Assignment---***Replaces some or all of the content of _str_
(that should read 'str' in my opinion).***
Quote: while the X_2
function modifies a local copy.
With a basic assignment statement like this:
Quote: str = 'X' + str[ 1..-1 ]
'=' is not the name of a String method. Instead:
---
This form of assignment is hardwired into the language.
---
(pickaxe2, p. 90)
And that type of assignment in ruby works like this:
If you write this:
x = 10
you get this:
x --> 10
In other words, x refers to 10. If you then write:
y = 10
you get:
x-----> 10
^
|
y ------+
Then if you write:
y = 20
you do not get:
x-----> 20
^
|
y ------+
Instead you get:
x ----> 10
y ----> 20
I like to think of it like this: with that basic type of assignment you
take the variable name on the left of the assignment, 'y' in this case,
and write it on a stick-it note, and paste the stick-it note on the
object on the right, the object 20. If ruby has already written the
same variable name on a stick-it note and pasted it on some other object
prior to your assignment statement(in the same scope), then ruby tears
the stick-it note off the other object and pastes it on the object 20.
--
Posted via http://www.ruby-forum.com/. |
|
|
| Back to top |
|
|
|
| 7stud --... |
| Posted: Sun Nov 01, 2009 4:27 am |
|
|
|
Guest
|
7stud -- wrote:
Because you mentioned C++, I'll just point out that "ruby references"
are not like C++ reference types. In C++, a reference variable is an
alias for another variable, which means that both variables refer to the
same location in memory. If you use one of the variable names to change
what is at that location in memory, the other variable, because it
retrieves its value from the same location in memory, also refers to the
changed value.
In my ruby example above, x and y are not aliases--even though they
refer to the same object 10. As a result, when y is assigned a new
value, it does not affect x.
--
Posted via http://www.ruby-forum.com/. |
|
|
| Back to top |
|
|
|
| David A. Black... |
| Posted: Sun Nov 01, 2009 5:18 am |
|
|
|
Guest
|
Hi --
On Sun, 1 Nov 2009, Jordi Bunster wrote:
Quote: On Oct 31, 2009, at 1:03 PM, David A. Black wrote:
I don't think "replace" has any generalizable semantics. You can't
replace 2 with 3, for example (fortunately :-)
You could just memcpy a to b (as long as their classes are eql?). If for a
given object it doesn't make sense, like for singleton ones, then you don't
allow it.
I wonder if they would take a patch. Is not as if Ruby doesn't already have a
ton of edge cases anyway.
The "There's a precedent" argument can always be inverted, though,
into the "We've reached our quota" argument Of course, that's
where Matz and his wonderful sense of balance come in.
In any case, I wouldn't call such a method "replace", because it's
radically different from the existing replace methods. Somewhere
there's at least one implementation (maybe in evil.rb) of a method
called "become", which I think does what you're describing, or
something similar: a.become(b) means that all existing references to a
become references to b, if I'm remembering/summarizing correctly.
David
--
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com
David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com) |
|
|
| Back to top |
|
|
|
| Rick DeNatale... |
| Posted: Sun Nov 01, 2009 11:53 pm |
|
|
|
Guest
|
On Sat, Oct 31, 2009 at 5:50 PM, Dave Anderson <anderson at (no spam) crocker.com> wrote:
Quote: One practical thing I can draw out of this is the difference between
these two functions:
def X_1( str )
str[0] = 'X'
end
def X_2( str )
str = 'X' + str[ 1..-1 ]
end
The X_1 function alters the passed-in object in place, while the X_2
function modifies a local copy. I don't recall reading this in the
literature anywhere.
Actually, the X_2 function doesn't make a local copy of the string
passed as the argument.
It ends up creating three new strings.
1 A copy of the literal string 'X'
2 A string which is the result of str[1..-1]
3 A string which is the concatenation of strings 1 and 2 which is then
bound to the local variable str. and will be the result of the method
call since it's the last expression and the value of an assignment
expression is the right hand side of the assignment.
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Thu Nov 26, 2009 3:47 am
|
|