T
Trans
On my further considerations of code redistribution (from my
perspective of Facets)...
I think one of the fundamental distinctions that I've been missing is
that which lies between a common utility and a more specialized tool.
For example, the Command base class is more specialized, while the
ANSICode module is more a common utility. Ultimately I think it would
be nice to create a more cohesive tool that covers the full- spectrum
of requirements for console based apps. While it would make sense to
include all the components needed for this in the single package,
eg."Comrade", this would discourage others from using those parts for
their own equivalent utilities. In other words, by including ANSICode
in "Comrade", I've discouraged others from creating there own command-
line solutions that could re-utilize ANSICode. For this reason, one
can argue that something like ANSICode would be better off as it's own
package.
However packaging systems are generally poorly suited to small
reusable libs like this, which typically having but a single file. For
example, RubyGems package format and conventions for project layouts
are bulky relative to this need, and it is inefficient in it's effects
on Ruby's loadpath system. Also, it may be foolish to think an
ANSICode library would get much independent use anyway. If someone
needed it for another application they'd might just copy and paste it
into their own project --avoiding the dependency. That's the other
issue here. With so many small libraries one could easily have dozens
of such dependencies per application. While that upholds the common
mantra of "code reuse", it also comes at the practical costs of
dependency. This is the primary reason I came up with the idea of
GemBundles.
So I suppose I have to ask, what is the goal? Is it to create
comprehensive solutions such as Comrade? Or simply to offer
essentially independent reusable components such as ANSICode? And if
the later, is it acceptable to distribute so many small packages, or
must we accept packaged groups even though it may discourage reuse?
T.
perspective of Facets)...
I think one of the fundamental distinctions that I've been missing is
that which lies between a common utility and a more specialized tool.
For example, the Command base class is more specialized, while the
ANSICode module is more a common utility. Ultimately I think it would
be nice to create a more cohesive tool that covers the full- spectrum
of requirements for console based apps. While it would make sense to
include all the components needed for this in the single package,
eg."Comrade", this would discourage others from using those parts for
their own equivalent utilities. In other words, by including ANSICode
in "Comrade", I've discouraged others from creating there own command-
line solutions that could re-utilize ANSICode. For this reason, one
can argue that something like ANSICode would be better off as it's own
package.
However packaging systems are generally poorly suited to small
reusable libs like this, which typically having but a single file. For
example, RubyGems package format and conventions for project layouts
are bulky relative to this need, and it is inefficient in it's effects
on Ruby's loadpath system. Also, it may be foolish to think an
ANSICode library would get much independent use anyway. If someone
needed it for another application they'd might just copy and paste it
into their own project --avoiding the dependency. That's the other
issue here. With so many small libraries one could easily have dozens
of such dependencies per application. While that upholds the common
mantra of "code reuse", it also comes at the practical costs of
dependency. This is the primary reason I came up with the idea of
GemBundles.
So I suppose I have to ask, what is the goal? Is it to create
comprehensive solutions such as Comrade? Or simply to offer
essentially independent reusable components such as ANSICode? And if
the later, is it acceptable to distribute so many small packages, or
must we accept packaged groups even though it may discourage reuse?
T.