RCR discussion: safety considerations

[Phil Tomson]

I want to have a discussion on certain safety issues and then submit some
RCRs. Safety as in avoiding name collisions, etc.

In another thread some issues were raised about certain 'dangerous'
practices common within the Ruby community that could limit Ruby's
acceptance in some circles.

The first one is being able to add/change methods in base classes.
Personally, I consider this a great feature (the 'add' part much more than
the 'change' part - changing methods in base classes should be avoided),
but some consider it dangerous in a production environment. To make them
feel more comfortable, what if we added a command line option that would
essentially freeze all built-in classes/modules when Ruby starts up?

What about introducing different 'freeze levels'? For example one level
would allow you to add methods to built-in classes but would not allow you
to redefine existing methods. Another level would disallow both. The
default level would of course be no freeze (as things are now).

Another issue that was raised was that Ruby doesn't have effective methods
(or at least not as effective as other languages have) of avoiding
namespace collisions. For example, when we 'include' a module we get all
of the methods in that module imported into the current
namespace. What if we could optionally list the methods/classes we want
to include, similar to Python's import:

import Blah func1,func2,MyClass

This imports the methods func1 and func2 and the class MyClass from Blah.
Perhaps similar options could be added to 'require'.

Thoughts? Is this necessary? Is it advisable?

Could Ruby use some air bags and seatbelts?

Phil

 

[Mauricio Fernández]

Another issue that was raised was that Ruby doesn't have effective methods
(or at least not as effective as other languages have) of avoiding
namespace collisions. For example, when we 'include' a module we get all
of the methods in that module imported into the current
namespace. What if we could optionally list the methods/classes we want
to include, similar to Python's import:

import Blah func1,func2,MyClass

IMHO this handles a pretty benign issue, as methods in the current class
will be preferred to those of a mix-in. It does nothing to solve the
following, however:

module Bar # idiotic code
def foo
1 + bar(1, 2, 3)
end
def bar(*a)
1
end
end

class Foo
include Bar # , :foo
def bar # changing the interface
"bla"
end
end

Foo.new.foo # booboo

And in the following case...
module Foo
def foo; ...; bar; ...; end
def bar; ... end
end
module Bar
def bar; ... end
end
class A
include Bar
include Foo, :foo # bar too?
end

This imports the methods func1 and func2 and the class MyClass from Blah.
Perhaps similar options could be added to 'require'.

I cannot think of any meaningful semantics for require 'foo', :blah.

Thoughts? Is this necessary? Is it advisable?

What problem does include Bar, :bla solve in addition to 'feature
deficit'?

--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

<SomeLamer> what's the difference between chattr and chmod?
<SomeGuru> SomeLamer: man chattr > 1; man chmod > 2; diff -u 1 2 | less
-- Seen on #linux on irc

 

[Phil Tomson]

IMHO this handles a pretty benign issue, as methods in the current class
will be preferred to those of a mix-in. It does nothing to solve the
following, however:

module Bar # idiotic code
def foo
1 + bar(1, 2, 3)
end
def bar(*a)
1
end
end

class Foo
include Bar # , :foo
def bar # changing the interface
"bla"
end
end

Foo.new.foo # booboo

And in the following case...
module Foo
def foo; ...; bar; ...; end
def bar; ... end
end
module Bar
def bar; ... end
end
class A
include Bar
include Foo, :foo # bar too?
end


I cannot think of any meaningful semantics for require 'foo', :blah.


What problem does include Bar, :bla solve in addition to 'feature
deficit'?

Perhaps you're right. Being able to pick & choose what methods to include
from a module probably isn't all that useful. If you're worried about
namespace collisions you can always do:
ModuleName::func

Also, people tend to include instance variables in Modules and if you
don't include the module's 'constructor' you may not set these up
correctly.

Anyway, since this hasn't turned into an active thread I would tend to
think that most people just don't see the need, so I probably won't file
any RCRs in this area.

....Though the freeze levels idea might be worthy of an RCR.


Phil