I’d rather call this “namespace” because that’s what the module is all
about here. IMHO this is the best approach for custom libs because it
helps keep namespaces clean. Also, if someone is using classes from
this module only, it’s easy to place an include Foo at the top of the
script to pull all classes defined in Foo into the current namespace.
end
IMHO that’s the worst of all presented approaches because it combines
two mechanisms that create dependencies between classes (inheritance and
nesting) that support different aims. I’d use nesting for classes that
are closely related to the outer class and make most sens in this
connection. Inheritance (besides delegation) is the usual way to extend
classes, probably even from another module / lib.
class Bar < Foo
end
end
I haven’t seen this one and would not do it because it does not ensure
proper use of namespaces.
BY NAME
No container modules, just use naming:
class Foo
end
class BarFoo < Foo
end
I would not use this one in a custom lib because namespaces are really a
better grouping mechanism than name suffixes. Even if you use BarFoo as
subclass name I’d rather do it in a module.
Which is better? Are there serious advantages/disadvantages to any of
these?
There are probably more pros and cons but when I would be writing a lib
I’d certainly use the first approach.
The only reason this is popular - or even exists at all - is because it
was introduced by rails. I don’t think this naming was ever used before
rails, and for good reason; what kind of name is “Base”?
Which is better? Are there serious advantages/disadvantages to any of
these?
As far as naming is concerned I don’t think you can objectively select a
“best” approach; semantics are too subjective. But the “base class”
approach does have the property of isolating constants defined in the
container namespace whereas the “container class” approach does not:
class A
K = 1
class B < A
end
end
A::B #=> 1
A::C::B #=> 1
Whether you consider that an advantage or an drawback is up to you.
The only reason this is popular - or even exists at all - is because it
was introduced by rails. I don’t think this naming was ever used before
rails, and for good reason; what kind of name is “Base”?
Ah, but all your base belong to us!
are belong to us
Sorry could not resist
The only reason this is popular - or even exists at all - is because it
was introduced by rails. I don’t think this naming was ever used before
rails, and for good reason; what kind of name is “Base”?
Could you explain further what you mean by “does not ensure proper
use”.
Foo is not part of the namespace but its subclasses are. Considering
that they seem to be part of one library and thus closely related I find
this separation “improper” because it a) clutters the global namespace
more than necessary and b) it separates things that rather belong together.
I haven’t seen this one and would not do it because it does not ensure
proper use of namespaces.
Sorry for the delayed response on this. So very busy.
Could you explain further what you mean by “does not ensure proper
use”.
Foo is not part of the namespace but its subclasses are. Considering
that they seem to be part of one library and thus closely related I find
this separation “improper” because it a) clutters the global namespace
more than necessary and b) it separates things that rather belong
together.
Kind regards
robert
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.