Home > Archive > Ruby > March 2005 > strip and its evil brother strip!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
strip and its evil brother strip!
|
|
| Aquila 2005-03-19, 4:00 pm |
| Possibly a stupid question: why does strip! of a string with a single
character in it give nil and strip the single character?
I don't understand the behaviour of strip!...
--
"May the source be with you"
| |
| Glenn Parker 2005-03-19, 4:00 pm |
| Aquila wrote:
> Possibly a stupid question: why does strip! of a string with a single
> character in it give nil and strip the single character?
> I don't understand the behaviour of strip!...
Looks like a bug to me.
$ ruby -e 'p " x ".strip!'
"x"
$ ruby -e 'p "x".strip!'
nil
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
| |
| Florian Gross 2005-03-19, 4:00 pm |
| Glenn Parker wrote:
> Aquila wrote:
>
>
>
> Looks like a bug to me.
>
> $ ruby -e 'p " x ".strip!'
> "x"
>
> $ ruby -e 'p "x".strip!'
> nil
This is by design. The destructive forms of built-in methods usually
return nil when they do nothing.
| |
| Jason Sweat 2005-03-19, 4:00 pm |
| On Sun, 20 Mar 2005 01:07:15 +0900, Glenn Parker
<glenn.parker@comcast.net> wrote:
> Aquila wrote:
>
> Looks like a bug to me.
>
> $ ruby -e 'p " x ".strip!'
> "x"
>
> $ ruby -e 'p "x".strip!'
> nil
This came up on another thread recenly. It is a legacy behavior of the
*! functions that they return nil if nothing changed.
Regards,
Jason
http://blog.casey-sweat.us/
| |
| David A. Black 2005-03-19, 4:00 pm |
| Hi --
On Sun, 20 Mar 2005, Jason Sweat wrote:
> On Sun, 20 Mar 2005 01:07:15 +0900, Glenn Parker
> <glenn.parker@comcast.net> wrote:
>
> This came up on another thread recenly. It is a legacy behavior of the
> *! functions that they return nil if nothing changed.
I don't think it's legacy in the sense that that usually implies
(something that's left over from an older design). That's just the
way they behave.
David
--
David A. Black
dblack@wobblini.net
| |
| Daniel Amelang 2005-03-19, 4:00 pm |
| I ranted about this very behavior 2 days ago. I'm willing to do an RCR
if anyone agrees (hint, hint).
http://blade.nagaokaut.ac.jp/cgi-bi...uby-talk/133894
On Sun, 20 Mar 2005 01:56:40 +0900, David A. Black <dblack@wobblini.net> wrote:
> Hi --
>
> On Sun, 20 Mar 2005, Jason Sweat wrote:
>
>
> I don't think it's legacy in the sense that that usually implies
> (something that's left over from an older design). That's just the
> way they behave.
>
> David
>
> --
> David A. Black
> dblack@wobblini.net
>
>
| |
| Gavin Kistner 2005-03-19, 4:00 pm |
| On Mar 19, 2005, at 10:04 AM, Daniel Amelang wrote:
> I ranted about this very behavior 2 days ago. I'm willing to do an RCR
> if anyone agrees (hint, hint).
>
> http://blade.nagaokaut.ac.jp/cgi-bi...uby-talk/133894
I experience the same pain, and would vote for such an RCR
| |
| Glenn Parker 2005-03-19, 4:01 pm |
| Florian Gross wrote:
>
> This is by design. The destructive forms of built-in methods usually
> return nil when they do nothing.
Yup, my bad. I know (really!) that this is by design, but I got myself
 while writing such a simple reply.
For me, chaining methods is part of the Ruby way. Sacrificing the
ability to easily chain method! calls was a mistake, IMHO. I still trip
over this anomoly, and not once have I needed the functionality that
took its place.
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
| |
| Florian Gross 2005-03-19, 4:01 pm |
| Glenn Parker wrote:
>
> Yup, my bad. I know (really!) that this is by design, but I got myself
> while writing such a simple reply.
>
> For me, chaining methods is part of the Ruby way. Sacrificing the
> ability to easily chain method! calls was a mistake, IMHO. I still trip
> over this anomoly, and not once have I needed the functionality that
> took its place.
I tend to disagree as destructive methods are not supposed to be
chained. They are optimized forms when you would be doing a variable
assignment, IMHO.
So they are optimizations for this case:
a = a.strip
But not for this case:
puts a.strip
While you might argue that modifying a String can be faster than
constructing a new one based on the old one, I still think that that is
not what matz had in mind when adding them. I'm not sure if this truly
is how this feature was meant to be used so it's probably best to take
this with a grain of salt until matz has clarified the situation.
| |
| Glenn Parker 2005-03-19, 4:01 pm |
| Florian Gross wrote:
>
> I tend to disagree as destructive methods are not supposed to be
> chained. They are optimized forms when you would be doing a variable
> assignment, IMHO.
>
> So they are optimizations for this case:
>
> a = a.strip
>
> But not for this case:
>
> puts a.strip
Who (else) ever said destructive methods are not supposed to be chained?
I'm thinking more of this somewhat contrived, but broken, case:
words = gets.chomp!.strip!.downcase!.gsub!(/[^a-z]/, '').split(/ /)
Unless and until object creation overhead is greatly reduced, this is a
worthwhile idiom.
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
| |
| Martin DeMello 2005-03-19, 4:01 pm |
| Florian Gross <flgr@ccan.de> wrote:
> So they are optimizations for this case:
>
> a = a.strip
It'd be nice to similarly optimise
a.strip!.upcase!
without ever having to create and discard a new object.
martin
| |
|
|
In data 3/19/2005, "Martin DeMello" <martindemello@yahoo.com> ha
scritto:
>Florian Gross <flgr@ccan.de> wrote:
>
>It'd be nice to similarly optimise
>
>a.strip!.upcase!
>
>without ever having to create and discard a new object.
I'd contend it's not even about optimization. Simply
_conceptually_ it's cleaner if, when I want to change
object x, I can actually do so rather than create a new
object and fiddle with 'references' and 'variables'.
>martin
E
| |
| Bill Guindon 2005-03-19, 4:01 pm |
| On Sun, 20 Mar 2005 02:38:50 +0900, Glenn Parker
<glenn.parker@comcast.net> wrote:
> Florian Gross wrote:
>
> Yup, my bad. I know (really!) that this is by design, but I got myself
> while writing such a simple reply.
>
> For me, chaining methods is part of the Ruby way. Sacrificing the
> ability to easily chain method! calls was a mistake, IMHO. I still trip
> over this anomoly, and not once have I needed the functionality that
> took its place.
I've always wondered about the "return nil if unchanged". I don't
believe I've ever used it, but I'm sure I've bumped into it a few
times where I didn't want to.
How often is this used/useful? I can see using it as part of an 'if'
statement, just can't think of why I would.
Anybody out there using the nil return on a regular basis? To the
point that it's worth sacrificing chaining?
--
Bill Guindon (aka aGorilla)
| |
| James Edward Gray II 2005-03-19, 8:58 pm |
| On Mar 19, 2005, at 11:49 AM, Florian Gross wrote:
> While you might argue that modifying a String can be faster than
> constructing a new one based on the old one, I still think that that
> is not what matz had in mind when adding them. I'm not sure if this
> truly is how this feature was meant to be used so it's probably best
> to take this with a grain of salt until matz has clarified the
> situation.
I like the current behavior and have used it in if statements more than
once, just to throw another log on the fire...
James Edward Gray II
| |
| Nikolai Weibull 2005-03-19, 8:58 pm |
| * Gavin Kistner (Mar 19, 2005 19:11):
[color=darkred]
[color=darkred]
> I experience the same pain, and would vote for such an RCR
Exactly when do you experience this pain? Perhaps you need some
aspirin?
Seriously, if you think using bang-methods is painful, I'd suggest not
using them at all. Use non-destructive methods instead. The
tradeoff in speed is negligible for anyting but real large
iteration-counts, e.g., in the area of perhaps five million and beyond.
At that point, it'd probably be better to come up with some special
method for doing what you're trying to do (although on my machine doing
one million
line.strip.downcase
takes 1.7 seconds (the banged version takes 1.2 seconds), so I'm not
really worried, I'd be more worried with how I'd store the result if
that's what the task is. (Actually, I'm guessing a large portion of
those 0.5 seconds are due to the garbage collector being invoked for the
non-banged one, but please remember that it's only a guess.)
I'd like to propose an RCR that would abolish the destructive versions
of methods in String and other standard classes. They're simply too
confusing (discussions such as these prove me right) and their uses,
if any, are usually symptoms of code that should be written differently.
I'm only half serious, but please realize that those methods are
suffixed by a bang for a very good reason,
nikolai
P.S.
It's strange, but the more I work with Ruby, the more I realize how
beautiful languages like Haskell and Clean really are. There are good
reasons for having languages free of side-effects. Still, I'd rather
program Ruby than spend my time wrestling a type-system that makes my
head spin.
Remember: the great thing about dynamic languages is not that you don't
have to write type-declarations, it's that you can write anything you
like for all the parts of the system that never get run!
D.S.
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
| |
|
|
In data 3/19/2005, "James Edward Gray II" <james@grayproductions.net>
ha scritto:
>On Mar 19, 2005, at 11:49 AM, Florian Gross wrote:
>
>
>I like the current behavior and have used it in if statements more than
>once, just to throw another log on the fire...
I can see that in some cases; on the other hand chaining
would be enormously fun and useful.
In the end, though, this just ties in with one of my
firmly held beliefs: the success or failure of an
operation should be indicated separately of its
return value.
>James Edward Gray II
E
| |
| Bill Kelly 2005-03-19, 8:58 pm |
| From: "Bill Guindon" <agorilla@gmail.com>
>
> I've always wondered about the "return nil if unchanged". I don't
> believe I've ever used it, but I'm sure I've bumped into it a few
> times where I didn't want to.
>
> How often is this used/useful? I can see using it as part of an 'if'
> statement, just can't think of why I would.
>
> Anybody out there using the nil return on a regular basis? To the
> point that it's worth sacrificing chaining?
I've only used it occasionally. But as Matz pointed out
awhile back,
http://ruby-talk.org/cgi-bin/scat.r...ruby-talk/17764
if you do need to know whether the object was modified,
there's no other way to get that information as cheaply.
Regards,
Bill
| |
| Nikolai Weibull 2005-03-19, 8:58 pm |
| * ES (Mar 19, 2005 22:40):
[color=darkred]
[color=darkred]
> I can see that in some cases; on the other hand chaining would be
> enormously fun and useful.
Fun?
> In the end, though, this just ties in with one of my firmly held
> beliefs: the success or failure of an operation should be indicated
> separately of its return value.
How would the success or failure of strip! be returned exactly?,
nikolai
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
| |
|
|
In data 3/19/2005, "Nikolai Weibull"
<mailing-lists.ruby-talk@rawuncut.elitemail.org> ha scritto:
>* ES (Mar 19, 2005 22:40):
>
>
>
>Fun?
'Conceptually better'.
>
>How would the success or failure of strip! be returned exactly?,
> nikolai
Hey, I'm not a Computer Scientist :)
It could be given via the return value wrapped inside a
MethodCallResult [sic] structure.
x = line.strip
puts x if x.successful?
It could be given as a special variable/method.
x = line.strip
puts x if successful?
Or there could be an entirely new way.
# test.rb # test_handling.rbh
x = line.strip
puts x pass if not strip.successful?
E
| |
| Martin DeMello 2005-03-19, 8:58 pm |
| Nikolai Weibull <mailing-lists.ruby-talk@rawuncut.elitemail.org> wrote:
> How would the success or failure of strip! be returned exactly?,
Thread-local $variable?
martin
| |
| Nikolai Weibull 2005-03-19, 8:58 pm |
| * ES (Mar 19, 2005 23:10):
[color=darkred]
[color=darkred]
[color=darkred]
> 'Conceptually better'.
That's a rather weak statement.
[color=darkred]
[color=darkred]
> Hey, I'm not a Computer Scientist :)
Is that an excuse? So you may rant about strip! being broken but you
shouldn't be responsible for providing a viable solution to the problem?
> It could be given via the return value wrapped inside a
> MethodCallResult [sic] structure.
You're not using "sic" correctly. You use "sic" when you quote somebody
elses writing that contains an error to make a not that the error occurs
in the original and that you know about it. It is often considered
redundant, as you assume that your reader isn't clever enough to
understand that you probably quoted it correctly. The "sic" is usually
added to in some way discredit the source you are quoting (and proving
that you have nothing better to counter the argument being quoted with
than the person being quoted's ability to write correctly).
> x = line.strip
> puts x if x.successful?
Your example solution is broken, as we can't return anything but the
object receiving the strip!, or this whole discussion is pointless,
nikolai
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
| |
| Nikolai Weibull 2005-03-19, 8:58 pm |
| * Martin DeMello (Mar 19, 2005 23:20):
[color=darkred]
> Thread-local $variable?
I'm sorry, but that's just terrible,
nikolai
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
| |
|
| WTF is with the attitude?
Nikolai Weibull wrote:
> * ES (Mar 19, 2005 23:10):
>
>
>
>
>
>
>
>
>
> That's a rather weak statement.
I think it's a pretty strong statement. 'Conceptually better' code
tends to be easier to write and understand.
>
>
>
>
>
> Is that an excuse? So you may rant about strip! being broken but you
> shouldn't be responsible for providing a viable solution to the problem?
Yeah, it's an excuse. I'm not a language designer and my mental
faculties are in any case insufficient for such tasks. It was
offered as a 'disclaimer', if you wish. You may read further
down for further reasoning.
I'm not 'ranting' about strip! being 'broken'. I would favour the
RCR since, to me, it's _conceptually better_ to modify an object
when modification of that object is the desired behaviour and for
this purpose, current behaviour is undesirable.
That being said, we're just tossing ideas around.
>
>
> You're not using "sic" correctly. You use "sic" when you quote somebody
> elses writing that contains an error to make a not that the error occurs
> in the original and that you know about it. It is often considered
> redundant, as you assume that your reader isn't clever enough to
> understand that you probably quoted it correctly. The "sic" is usually
> added to in some way discredit the source you are quoting (and proving
> that you have nothing better to counter the argument being quoted with
> than the person being quoted's ability to write correctly).
'Sic', latin. Literally, 'thus'. It here indicates a sentiment similar
to 'as it were'. You may be thinking of 'stat', which means 'so it was
originally'.
>
>
> Your example solution is broken, as we can't return anything but the
> object receiving the strip!, or this whole discussion is pointless,
I illustrated the concept of separation of return values and the
success of an operation. You may view solution number three for a
foray into more pertinent territory. Of course, solutions such as:
puts "failed: #{$err}" failing line.strip!.ok?.downcase!.ok?.split(//)
# => failed: Nothing to strip
Where #ok? returns the recipient on success or a 'devouring nil'
with an adjunct error code (or exception) on failure. The #ok?
is of course superfluous and could be omitted:
puts "failed: #{$err}" failing line.strip!.downcase!.split //
The separation is such a high-level concept that it's probably not
possible to extend any existing language to take full advantage of
it though a workable solution is quite viable.
> nikolai
E
| |
| Nikolai Weibull 2005-03-19, 8:58 pm |
| * ES (Mar 20, 2005 00:40):
> WTF is with the attitude?
Right back at you? Sorry for being a dick. I guess I should have
calmed down and thought my response through more thouroughly before
sending.
[color=darkred]
> I think it's a pretty strong statement. 'Conceptually better' code
> tends to be easier to write and understand.
Yes, but just saying that it's conceptually better without giving a good
reason for it doesn't really mean anything. Your solution for working
around the problem that the solution that you argue is conceptually
better just leads to another problem, a problem that so far doesn't have
an obvious solution (i.e., what is discussed below--how to check for
success). So it doesn't seem to be conceptually better, at least to me.
[color=darkred]
[color=darkred]
> 'Sic', latin. Literally, 'thus'. It here indicates a sentiment similar
> to 'as it were'. You may be thinking of 'stat', which means 'so it was
> originally'.
No, that's not what I'm thinking of. It is used precisely as I
described. It is not, in English, used as you suggest. I was not
trying to be rude by pointing this out. I apologize if you thought it
to be so.
> puts "failed: #{$err}" failing line.strip!.downcase!.split //
> The separation is such a high-level concept that it's probably not
> possible to extend any existing language to take full advantage of it
> though a workable solution is quite viable.
Yes, but introducing additional language constructs to solve a problem
introduced by the solution of a, to me, non-problem seems very costly.
The best solution, it seems to me, would be to remove the destructive
versions of these methods. I guess we're returning to the whole
immutable versus mutable strings discussion again. Anyway, I'm not
advocating the removal of all destructive methods. They're viable for
hashes and arrays, which can be very costly to create anew, but strings
are meant to be short by their very nature, as they are stored
continuously in memory, and can then be copied rather efficiently. I
have suggested earlier that what we perhaps need is a second
string-like, or sequence, class that is better suited for doing a lot of
transformations. I will try to put my money where my mouth is, but I'm
strained for time as it is. I guess I shouldn't be spending so much
time trolling on this mailing-list...,
nikolai
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
| |
| Mathieu Bouchard 2005-03-20, 8:58 pm |
|
On Sun, 20 Mar 2005, Daniel Amelang wrote:
> I ranted about this very behavior 2 days ago. I'm willing to do an RCR
> if anyone agrees (hint, hint).
> http://blade.nagaokaut.ac.jp/cgi-bi...uby-talk/133894
One thing I dislike about the Smalltalk-style habit of returning self when
there is otherwise no return value, is that this return value is something
you already have, and it gets in the way of ex-post-facto extending your
interface by making the method return a meaningful value.
In the case of Ruby, the return value is essentially a boolean telling you
whether any modifications had to be done, but somehow, instead of using
true vs false, it's self vs nil. I don't know why.
Smalltalk also has an alternate mechanism at the syntax level, for making
several methodcalls to a receiver written only once. This makes returning
self sound even stupider to me in that context. I wish Ruby had a similar
feature so that methods never have to return systematically self and so
whenever such a thread appears we could point people to that feature.
Example (with some extra spaces inserted, and supposing there are methods
named like that in Smalltalk)
Smalltalk: x chop strip.
Ruby: x.chop! .strip!
Smalltalk: x chop. x strip.
Ruby: x.chop!; x.strip!
Smalltalk: x chop; strip.
Ruby (no equivalent)
In the last version, x is only mentioned once, and the return value of
chop is discarded. I think it could be nice to have something like that in
Ruby.
________________________________________
_____________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
| |
| George Ogata 2005-03-21, 3:58 am |
| Mathieu Bouchard <matju@sympatico.ca> writes:
> Smalltalk: x chop; strip.
> Ruby (no equivalent)
>
> In the last version, x is only mentioned once, and the return value of
> chop is discarded. I think it could be nice to have something like that in
> Ruby.
Perhaps:
x.instance_eval{chop!; strip!}
Alias to taste. Locals can get in the way for most method names,
though.
| |
| Martin DeMello 2005-03-21, 8:57 am |
| Nikolai Weibull <mailing-lists.ruby-talk@rawuncut.elitemail.org> wrote:
> * Martin DeMello (Mar 19, 2005 23:20):
>
>
> I'm sorry, but that's just terrible,
Not really any more terrible than overloading the return value of a function
to indicate success or failure. I like lisp's solution of getting the
'main' return value using the function call, and the entire set using
multiple-value-bind, but that's probably not feasible in ruby.
martin
| |
| Christian Neukirchen 2005-03-21, 4:01 pm |
| Mathieu Bouchard <matju@sympatico.ca> writes:
> On Sun, 20 Mar 2005, Daniel Amelang wrote:
>
> Smalltalk also has an alternate mechanism at the syntax level, for making
> several methodcalls to a receiver written only once. This makes returning
> self sound even stupider to me in that context. I wish Ruby had a similar
> feature so that methods never have to return systematically self and so
> whenever such a thread appears we could point people to that feature.
+1
> Example (with some extra spaces inserted, and supposing there are methods
> named like that in Smalltalk)
>
> Smalltalk: x chop strip.
> Ruby: x.chop! .strip!
>
> Smalltalk: x chop. x strip.
> Ruby: x.chop!; x.strip!
>
> Smalltalk: x chop; strip.
> Ruby (no equivalent)
>
> In the last version, x is only mentioned once, and the return value of
> chop is discarded. I think it could be nice to have something like that in
> Ruby.
For Ruby2, I'd love to have this too.
> Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
| |
| Csaba Henk 2005-03-21, 4:01 pm |
| On 2005-03-20, Mathieu Bouchard <matju@sympatico.ca> wrote:
> Example (with some extra spaces inserted, and supposing there are methods
> named like that in Smalltalk)
>
> Smalltalk: x chop strip.
> Ruby: x.chop! .strip!
>
> Smalltalk: x chop. x strip.
> Ruby: x.chop!; x.strip!
>
> Smalltalk: x chop; strip.
> Ruby (no equivalent)
There _is_ equivalent of this in ruby, it's just it's not sugared:
x.instance_eval { chop; strip }
But you can see that this form makes difference semantically: without it
you should do
s = "ab#{foo}de"[1..3]
s.chop!
s.strip!
The above form saves you that local assignment:
"ab#{foo}de"[1..3].instance_eval { chop!; strip! }
I wonder why isn't #instance_eval sugared. It's a very useful method,
and I think only its ugly lengthy names keeps it away from becoming one
of the most basic rubyisms. It's not even some weirdo which is justified
to have weird name because of its weirdness.
Eg., it could be just aliased to Kernel#do. (Don't tell me that "do" also
being a keyword is a problem while we have this also with "class" [that
one annoys me more that this would].) Let's get a visual impression of
it:
x.do { chop!; strip! }
I like it...
Csaba
| |
| Florian Gross 2005-03-21, 4:01 pm |
| Csaba Henk wrote:
> Eg., it could be just aliased to Kernel#do. (Don't tell me that "do" also
> being a keyword is a problem while we have this also with "class" [that
> one annoys me more that this would].) Let's get a visual impression of
> it:
>
> x.do { chop!; strip! }
What about the multi-line form?
x.do do
chop!
strip!
end
So I think that "do" is indeed a bad method name for this...
Perhaps we should just go with Kernel#with:
with(x) do
chop!
strip!
end
But then the question is whether this should return the value of the
last statement or its argument...
| |
| Csaba Henk 2005-03-21, 4:01 pm |
| On 2005-03-21, Florian Gross <flgr@ccan.de> wrote:
> What about the multi-line form?
>
> x.do do
> chop!
> strip!
> end
>
> So I think that "do" is indeed a bad method name for this...
Yeah, that's somewhat bizarre... But not that bad. You could just stick
to the bracy version if you don't want to write funny code. Or
instance_eval and the do keyword if you feel that "do" is the
appropriate block delimiter somewhere.
If you have a code block of seven lines, your priority is not being
oversugared, rather being readable. If you just want to chain two method
calls, then the sugar comes handy. Thus there were no reason to abuse
the language in the above way.
> Perhaps we should just go with Kernel#with:
>
> with(x) do
> chop!
> strip!
> end
>
> But then the question is whether this should return the value of the
> last statement or its argument...
You'd throw away object orientedness just to have fancy natural language
resemblence? I think that we may call #instance_eval by whatever name,
it should be a method of the given object.
Ok, then what about the following perverted idea: as now putting a
pair of parens after something which is not a method falls back to a
call to #call, why not make a fallback for
x { block }
as
x.instance_eval { block }
?
Csaba
| |
| Florian Gross 2005-03-21, 4:01 pm |
| Csaba Henk wrote:
>
> You'd throw away object orientedness just to have fancy natural language
> resemblence? I think that we may call #instance_eval by whatever name,
> it should be a method of the given object.
Not every form of syntax sugar has to have the object on the left-handed
side IMHO.
| |
| Mathieu Bouchard 2005-03-22, 4:00 am |
|
On Mon, 21 Mar 2005, Csaba Henk wrote:
> On 2005-03-20, Mathieu Bouchard <matju@sympatico.ca> wrote:
> There _is_ equivalent of this in ruby, it's just it's not sugared:
> x.instance_eval { chop; strip }
> But you can see that this form makes difference semantically: without it
> you should do
> s = "ab#{foo}de"[1..3]
> s.chop!
> s.strip!
> The above form saves you that local assignment:
> "ab#{foo}de"[1..3].instance_eval { chop!; strip! }
The problem with it, compared to the smalltalk one, is that it changes the
scope of instance-variables.
> It's a very useful method, and I think only its ugly lengthy names
> keeps it away from becoming one of the most basic rubyisms.
I often use "i" as an abbreviation for instance. I write "ivar" instead of
"instance variable". Even the C/Ruby API calls them that way. However, the
subtext of such a phrase annoys me. It suggests a binary opposition that
asserts the supremacy of the classes over other objects, and effectively
even ejects the name "object" in favour of some statement of dependency
(it's always about being an instance _of_ something). I'd rather have them
called "object variables" or "ovar" but if not then i can accept "ivar" as
long as i don't de-abbreviate it.
(yes, i'm slightly exaggerating, but this should show that Ruby is much
closer to class-based OOP than to prototype-based OOP.)
More important than the above, though, is the fact that in
instance_methods and instance_variables, the meaning of "instance" is
confusing: in one, you're looking at things that belong to a class but
applies to its instances, and in the latter case, you're looking at things
that belong to a single object and applies only to itself, and per se have
nothing at all to do with classes and instantiation, beyond the fact that
most of those variables get set up during instantiation, but simply by
convention and not by necessity.
> It's not even some weirdo which is justified to have weird name
> because of its weirdness.
Weirdness is in the eye of the beholder... you see, some people have
learnt from the Church of JAVA (tm) that eval is evil and dirty (Ruby has
eval), that multiple inheritance is evil (Ruby has it too), that classes
are the centre of the world, that classes are and *have* to be the unit of
program reusability, that writing "protected static final void" all over
is normal, etc.
Ruby has so many people with different experiences, and thus so different
expectations of normalcy, given what they've been "raised with" when they
started computer programming.
(oh, and if you're not following my postmodernist reasonings, i'm sorry.)
________________________________________
_____________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
| |
| Yukihiro Matsumoto 2005-03-22, 4:00 am |
|
In message "Re: strip and its evil brother strip!"
on Mon, 21 Mar 2005 08:30:23 +0900, Mathieu Bouchard <matju@sympatico.ca> writes:
| Smalltalk: x chop; strip.
| Ruby (no equivalent)
|
|In the last version, x is only mentioned once, and the return value of
|chop is discarded. I think it could be nice to have something like that in
|Ruby.
Yep, cascading method call style has been sought several times in the
past, but we had not been able to think of a good syntax.
matz.
| |
| Csaba Henk 2005-03-22, 4:00 am |
| On 2005-03-22, Mathieu Bouchard <matju@sympatico.ca> wrote:
> The above form saves you that local assignment:
>
> The problem with it, compared to the smalltalk one, is that it changes the
> scope of instance-variables.
That's true. #instance_eval is not the same as what Smalltalk has, but
in the 90% percent of the cases when you'd just like to quickly throw
some thunks at the object in a line, it pretty well does the job.
>
>
> I often use "i" as an abbreviation for instance. I write "ivar" instead of
> "instance variable". Even the C/Ruby API calls them that way. However, the
> subtext of such a phrase annoys me. It suggests a binary opposition that
> asserts the supremacy of the classes over other objects, and effectively
> even ejects the name "object" in favour of some statement of dependency
> (it's always about being an instance _of_ something). I'd rather have them
> called "object variables" or "ovar" but if not then i can accept "ivar" as
> long as i don't de-abbreviate it.
Even then, you don't mention using "ieval" :)
>
> Weirdness is in the eye of the beholder... you see, some people have
Sure, what I spoke above is just my personal feeling.
> learnt from the Church of JAVA (tm) that eval is evil and dirty (Ruby has
[...]
> (oh, and if you're not following my postmodernist reasonings, i'm sorry.)
I liked them... Church of Java, sounds as mystic and exciting and
terrifying as the pirates with their treasures and iron hook hands and
half eye and wooden legs when I was a child :)
Csaba
| |
| Glenn Parker 2005-03-22, 4:00 am |
| Florian Gross wrote:
>
> Perhaps we should just go with Kernel#with:
>
> with(x) do
> chop!
> strip!
> end
>
> But then the question is whether this should return the value of the
> last statement or its argument...
Seems like it should be the value of the last expression, but that gets
us back to the question we started with.
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
| |
| Mathieu Bouchard 2005-03-31, 4:00 am |
|
On Tue, 22 Mar 2005, Csaba Henk wrote:
> On 2005-03-22, Mathieu Bouchard <matju@sympatico.ca> wrote:
> Even then, you don't mention using "ieval" :)
GridFlow (my video software) has a C++ macro called IEVAL(). However I
have not used the name "ieval" at the Ruby level yet: it all depends on
how often you use a name. I just don't have that much of a drive to define
a shortcut for instance_eval on the Ruby side.
The naming of things is influenced by how often those names are used.
Frequent names tend to become abbreviated. This is a common phenomenon in
natural languages, therefore it's something that many people do and that
does affect the language. It's a natural occurrence of Huffman/Shannon
compression in nature :-) I recall Larry Wall mentioned Huffman-coding of
function names, and I learned that idea from him.
Unfortunately, one thing I didn't learn from Larry is that most Perl
programmers aren't nearly as smart as Larry, and furthermore, they either
don't read Larry or don't understand him.
> [...]
> I liked them... Church of Java, sounds as mystic and exciting and
> terrifying as the pirates with their treasures and iron hook hands and
> half eye and wooden legs when I was a child :)
Well, to me, Church of Java sounds more like a cargo-cult in the jungle...
« Cargo cult is a term for a group of religious movements that occured
in Melanesia. These Cargo Cults believed that manufactured western
goods ('cargo') were created by ancestral spirits and intended for
Melanesian people. [...] »
-- http://en.wikipedia.org/wiki/Cargo_cult
________________________________________
_____________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
|
|
|
|
|