strip and its evil brother strip!

[Nikolai Weibull]

* ES (Mar 19, 2005 23:10):

'Conceptually better'.

That's a rather weak statement.

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

 

[Nikolai Weibull]

* Martin DeMello (Mar 19, 2005 23:20):

Thread-local $variable?

I'm sorry, but that's just terrible,
nikolai

 

[ES]

WTF is with the attitude?

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

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

'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]

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

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.

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

'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

 

[Mathieu Bouchard]

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-bin/scat.rb/ruby/ruby-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]

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]

* 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

 

[Csaba Henk]

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]

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]

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]

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]

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]

In message "Re: strip and its evil brother 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.

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]

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.

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]

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.

 

[Mathieu Bouchard]

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.

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

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