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’.
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’?
···
On Mon, Jan 19, 2004 at 01:25:01PM +0900, Phil Tomson wrote:
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’?
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.