WTF is with the attitude?

Nikolai Weibull wrote:
> * ES (Mar 19, 2005 23:10):
> 
>>>>>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.
> 
> 
>>>Fun?
> 
> 
>>'Conceptually better'.
> 
> 
> 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.

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

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

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

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