[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Software Reliability and method i/o

tsawyer

1/27/2005 7:03:00 AM

I've just finished reading the beginning of an interesting article on
software reliability at:

http://users.adelphia.net/~lilavois/Cosas/Reliability.ht...

There is one small part that cought my attention b/c something similar
came up recently in regards to pass-by reference.

"... all connectors should be unidirectional, i.e., they should be
either male (sender) or female (receiver). This will eliminate mix-ups
and ensure robust connectivity."

It was mentioned the previous thread that purely pass-by-value is
arguably the most "proper". But as we all know it is inefficient
--having to copy an object going in only to turn around and reassign it
whence it came:

a = amethod(a.dup)

So I'm wondering might it be possible for the language itself to be
intelligent enough to work as if it were pass-by-value, but catch
situations like the above and work with them on a pass-by reference
bases for efficency, all the while using a pass-by-reference-to-value
under the hood like Ruby currently uses?

In other words, no matter how it works underneath, for the
end-programmer the left side should always be male-output and the right
female-input, and never the twain shall meet.

T.

8 Answers

Curt Sampson

1/27/2005 9:29:00 AM

0

Austin Ziegler

1/27/2005 1:30:00 PM

0

On Thu, 27 Jan 2005 18:29:03 +0900, Curt Sampson <cjs@cynic.net>
wrote:
> One of the things I think Java did right was to make Strings
> immutable. One of the things I think Java did wrong was to make
> Dates mutable.

I'd have to completely disagree with you here. I think that Java's
choice to make Strings immutable has made the language much more
unpleasant to deal with, and results in a number of inefficiencies
when one -- inevitably -- must modify the contents of a string
object. Always using construction and concatenation isn't
acceptable, and the overhead of using StringBuffer all the time is
undesirable (especially since you have to construct a StringBuffer
every time you need to deal with this since everyone returns String
objects).

Matz got it right when he made Strings mutable. James and Guido
got it wrong.

-austin
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca


Trans

1/27/2005 2:49:00 PM

0


Curt Sampson wrote:
> Actually, you need pass by reference for arguments where you want the
> function to have side-effects affecting that argument.

That's my point. I'm not sure we do NEED them. Side-effects are exactly
the couse of concern which leads to more bugs and thus unreliable
software.

> I think a much better way of getting the kind of "reliability" you're
> talking about is to always pass by reference, but wherever you can,
use
> value objects. Methods that would "modify" a non-value object instead
> return a new value object with the modified state. For example,
>
> p1 = Point.new(17, 35);
> p2 = p1;
> p1 = p1.move(0, 5);
>
> Now p2 still refers to the point (17,35), but p1 has been changed to
> refer to a different point (17, 40) (rather than the point itself
> changing). This helps greatly to avoid aliasing.

Hm... but doesn;t that still leave it all up to the programmer? And it
is terribly inefficient.

> Avoiding side-effects as much as possible in this way is OO in sort
of a
> functional programming spirit.

Right. And I ownder if it isn;t worth enforcing --and finding
intelligent ways to to id it efficiently.

> One of the things I think Java did right was to make Strings
immutable.
> One of the things I think Java did wrong was to make Dates mutable.

Maybe so for the dates.

But I'm hinting at transcending this in a way with regards to argument
passing. Arguments would become as if immutable (and side effect must
enforce a duplication) unless it was seen that the passed object was
returning on output from the same place it came from on input. Does
that make sense?

T.

Curt Sampson

1/27/2005 11:38:00 PM

0

Curt Sampson

1/27/2005 11:46:00 PM

0

Trans

1/28/2005 2:04:00 AM

0

Curt Sampson wrote:
> On Thu, 27 Jan 2005, Trans wrote:
>
>
> Indeed. I'm coming more and more over toward the functional side.

Me too.

> > Hm... but doesn;t that still leave it all up to the programmer?
>
> Sure, but it's not hard if that's how the programming culture works.
And
> the only option beyond that is to make ruby purely functional, so
that
> it's impossible to have side-effects. Not even Scheme went that far.

But maybe it _is_ a good idea to go that far.

> > And it is terribly inefficient.
>
> Again, I don't buy this. Show me some proof.

Well, I shouldn't say terribly I guess. But it will be slower by the
simple fact that when passing by-value, a copy of the object must be
made. That operation, though very quick, will add up. I could do a
benchmark...maybe when I have more time.

> I understand that, but I don't like it because it's no longer simple.
> For example, when I read "a.foo(b, c)", which argument allows
> side-effects? Or is it neither? You have to go track down the
definition
> of foo to see what it returns, since there's no indication in that
bit
> of code.

Try this on for size. Calling 'a.foo(b,c)' flags the parameters b and c
as by-value, but nothing actually happens yet. Only if during the
course of executing foo should b (or c) be _affected_ does a copy get
made prior to the actual affect, and the copy is used from then on.
Sort of a lazy pass by-value. (Maybe this is how seme systems already
work?)

Now take a different example 'b = a.foo(b,c)'. Here b will be flaged as
_potentially_ by-reference. Now lets say foo is defined like:

| def foo(x,y)
| x << y
| x
| end

In this case b is simply returning to wence it came. If it were
possbile for the evaluator to see that fact, then the lazy by-value
copying could be omitted. Of course the trick is seeing that (is it
possible?).

It might help to look at a much simpler example:

x += y

Presently, of course, this creates a new object referenced by x. Yet
does it need to? Well, only if there are other references to x's
original object. If there are not then it may just as well be modified
in place, it won't effect anything.

Seems to me if this could be done then it would be by-value with much
of the efficency of by-reference; and also out of sight, out of mind to
the end-programmer. At least, thats the idea. I may have totally
overlooked something, and I don't now how feasibile it is either, or if
the loss in efficency from actually doing it counteracts the gain. But
it's an interesting notion at least.

T.

Austin Ziegler

1/28/2005 3:26:00 AM

0

On Fri, 28 Jan 2005 08:38:04 +0900, Curt Sampson <cjs@cynic.net> wrote:
> On Thu, 27 Jan 2005, Austin Ziegler wrote:
>> I'd have to completely disagree with you here. I think that
>> Java's choice to make Strings immutable has made the language
>> much more unpleasant to deal with....
> "Much more" unpleasant? I'd like to see some specifics on this.

Well, you'll notice that Java has very little that's actually built
for manipulating text, because the expense of String construction.
Frankly, the only thing that I like about the C++ std::string is
that it *is* mutable -- otherwise it's just as bad as the Java
String for usability.

-austin
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca


Curt Sampson

1/28/2005 5:29:00 AM

0