Asp Forum - [Rhetoric] Two feature requests for safer Ruby Programming

hemant

12/19/2007 10:18:00 AM

You can take my take on following issues with a pinch of salt, when
you disagree I perhaps know, why you disagree and generally respect
your opinion no matter how badly i disagree.

1. Image a new guy joins your rails team and he writes code like this
in a controller:

def get_quote(ticker)
# create a request string, that matches internal protocol
request = format_request_str(:quote, ticker)
# Market is a class that hold TCP connections to server that can
give stock market quotes
response = Market.get_response(request)
end

Above code is going to blow. Why? because request is a method
defined by ActionPack.
What can we do to prevent this? or this guy is simply dumb and
should stop programming?

Well in my opinion, the precious little that Ruby can do is to
enforce having '()' for method invocation.

Does that solve the problem? Heck no, what if our man goes and defines:

def request(request_type,ticker)
# create a request string and return it
end

There he is till shooting himself in foot. This brings second issue.

2. Adding methods to core classes, overriding core class methods,
silent override of methods inherited from parent classes
is a big problem with Ruby. Ruby absolutely gives no indication
that this has happened. Today, you may claim that
heck, I will stay away from such libraries ( quoting : raggi on
#ruby-lang ). Today you have that luxury, because even if a
library is not documented, you can see the source code of every
damn library and find out, what its doing.

You can stay safe that way. But this will not be the case in future.
JRuby, Ruby2.0, Rubinius,IronRuby are preparing a future where
compiled bytecode may be only thing that can be distributed. Again,
as a free software guy You can avoid such "evil" libraries.
But imagine, if you are using such a library and library is not very
well documented, you are in for a fun.

Another thing that I have seen with rubyists (including myself) is,
they don't really follow class encapsulation properly. What I mean,
you will rarely
see a library that uses :private and :protected properly. Why is
this? Because ease with which private methods can be called, people
don't really care.

It is dangerous, without source code, proper encapsulation and
silent override of a method, you are in for fun. But this
encapsulation issue is
just scratching the surface, even unindented override of public
methods is a potential hazard.

Whats the solution?

In my opinion, when unintended override of a method happens, Ruby
should throw a warning. To silent that warning, one should explicitly
say you are
overriding a method.

Thats about it.

--
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://g...

7 Answers

Sylvain Joyeux

12/19/2007 10:34:00 AM

> Above code is going to blow. Why? because request is a method
> defined by ActionPack.
> What can we do to prevent this? or this guy is simply dumb and
> should stop programming?
No. Local variables have higher precedence than method invocation. The
code works as expected (i.e. 'request' is the local variable, not the
method call).

> In my opinion, when unintended override of a method happens, Ruby
> should throw a warning. To silent that warning, one should explicitly
> say you are
> overriding a method.
See the -w flag

[~]% cat test.rb
class WarningAlreadyExists
def bla
end
end

class WarningAlreadyExists
def bla
end
end

[~]% ruby -w test.rb
test.rb:10: warning: method redefined; discarding old bla
--
Sylvain

hemant

12/19/2007 11:19:00 AM

On Dec 19, 2007 4:03 PM, Sylvain Joyeux
<sylvain.joyeux@polytechnique.org> wrote:
> > Above code is going to blow. Why? because request is a method
> > defined by ActionPack.
> > What can we do to prevent this? or this guy is simply dumb and
> > should stop programming?
> No. Local variables have higher precedence than method invocation. The
> code works as expected (i.e. 'request' is the local variable, not the
> method call).
>

Hmm, I wasn't aware of this. But in spite of this, I have seen issues
because of this.
Above code works, no doubt. I will try to reproduce the situation
where it truly creates problem.

> > In my opinion, when unintended override of a method happens, Ruby
> > should throw a warning. To silent that warning, one should explicitly
> > say you are
> > overriding a method.
> See the -w flag
>
> [~]% cat test.rb
> class WarningAlreadyExists
> def bla
> end
> end
>
>
> class WarningAlreadyExists
> def bla
> end
> end
>
> [~]% ruby -w test.rb
> test.rb:10: warning: method redefined; discarding old bla

I was aware of this, but what I also meant was:

class WarningAlreadyExists
def bla
end
end

class Foo < WarningAlreadyExists
def bla
end
end

Doesn't give any warnings, even with warning flag on.

--
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://g...

Marc Heiler

12/19/2007 12:00:00 PM

> Ruby can do is to enforce having '()' for method invocation.

How would that make them better programmers?

Enforcing behaviour sounds like the wrong way to go. You'd end up like
python - with fewers abilities to ever escape the mindset. And no way
to type "quit" in interactive python mode leading to quit that damn
thi** ;-)

Maybe the person in question just does not know either ruby, or the
parent class(es) he is using?
--
Posted via http://www.ruby-....

Rick DeNatale

12/19/2007 1:29:00 PM

On 12/19/07, Marc Heiler <shevegen@linuxmail.org> wrote:
> > Ruby can do is to enforce having '()' for method invocation.
>
> How would that make them better programmers?
>
> Enforcing behaviour sounds like the wrong way to go. You'd end up like
> python - with fewers abilities to ever escape the mindset. And no way
> to type "quit" in interactive python mode leading to quit that damn
> thi** ;-)
>
> Maybe the person in question just does not know either ruby, or the
> parent class(es) he is using?

Picking up on something Dave Thomas said in a talk I just watched
online, If the OP is afraid of letting his team use sharp scissors,
perhaps he should look elsewhere for a programming language.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Sylvain Joyeux

12/19/2007 2:18:00 PM

> I was aware of this, but what I also meant was:
>
> class WarningAlreadyExists
> def bla
> end
> end
>
>
> class Foo < WarningAlreadyExists
> def bla
> end
> end
>
> Doesn't give any warnings, even with warning flag on.
Of course it does not. You may have to learn some basic object-oriented
principles before complaining about robustness issues in languages.
Reimplementing a method in subclasses is the basis of polymorphism and
is the way to go in *all* object oriented languages I know of.
--
Sylvain

Richard Conroy

12/19/2007 3:08:00 PM

I'm with Marc on this. How does putting training wheels on the
language make them better programmers?
All it does is slow down the better guys. Weak/dishonest programmers
can write crap code in any language.

As for unencapsulated methods, Ruby programmers, (and any other
dynamic/succinct-syntax language
programmers) place greater emphasis on unit testing. Methods are left
accessible to facilitate effective
unit test coverage.

Even in really big java projects, I can't recall a single instance
where making a method private offered me any
real help or protection, but it did make unit testing very difficult,
and private methods IME are more likely to
have side effects.

Method sealing is generally just something that API/framework
developers need to concern themselves with.

Chris Cummer

12/19/2007 6:15:00 PM

On 19-Dec-07, at 6:18 AM, Sylvain Joyeux wrote:

>> I was aware of this, but what I also meant was:
>>
>> class WarningAlreadyExists
>> def bla
>> end
>> end
>>
>>
>> class Foo < WarningAlreadyExists
>> def bla
>> end
>> end
>>
>> Doesn't give any warnings, even with warning flag on.
> Of course it does not. You may have to learn some basic object-
> oriented
> principles before complaining about robustness issues in languages.
> Reimplementing a method in subclasses is the basis of polymorphism and
> is the way to go in *all* object oriented languages I know of.

Sylvain is correct. The "danger" you're objecting to here is in fact
exactly the desired behaviour.

Often a programming language can protect a developer but in this case,
if the over-riding were undesirable, then the error would be in
extending a class that the developer does not yet fully understand,
and not with the programming language.

Regards
Chris

comp.lang.ruby

[Rhetoric] Two feature requests for safer Ruby Programming

hemant

Sylvain Joyeux

hemant

Marc Heiler

Rick DeNatale

Sylvain Joyeux

Richard Conroy

Chris Cummer

x Login to ForumsZone