Hello all!
I’m planning on playing around with writing some sort of “package
manager” for source based Linux distros or any of the BSDs. I’m
thinking along the lines of Gentoo’s portage system or the BSD ports
system. I was toying around with modules with this idea, and I got
to wondering something. If a class needs a lot of different methods,
such as 30 or 40+ methods, and they’re all very specific to that class,
does it make sense to pull out a bunch of those methods and put them
into a module and mix them in later, or should they be kept in with the
class? For example, if I have an object that represents a software
tarball, and that object has a number of attributes such as
dependancies, reverse dependancies, comments, versions, etc, and then I
have all the methods that go with it for fetching, configuring,
building, resolving dependancies, etc, would it make more sense to keep
all those methods out of the class or leave them in the class, even
though it would make that class huge?
I realize it’s PROBABLY a matter of taste, but are there any good
reasons to do it one way or another?
Thanks for any input sent my way…
Jeremy
I suppose it depends on what kind of methods they are - for example, I
was very confused when I went looking for the File.exists? method in the
File class only to find that it was part of the Filetest mixin. I
suppose that class methods like those can be defined in a module. It
seems that all instance methods should be explicitly members of the
class, though.
-Kurt
···
On Thu, Aug 21, 2003 at 01:32:38PM +0900, Jeremy Whetzel wrote:
Hello all!
I’m planning on playing around with writing some sort of “package
manager” for source based Linux distros or any of the BSDs. I’m
thinking along the lines of Gentoo’s portage system or the BSD ports
system. I was toying around with modules with this idea, and I got
to wondering something. If a class needs a lot of different methods,
such as 30 or 40+ methods, and they’re all very specific to that class,
does it make sense to pull out a bunch of those methods and put them
into a module and mix them in later, or should they be kept in with the
class? For example, if I have an object that represents a software
tarball, and that object has a number of attributes such as
dependancies, reverse dependancies, comments, versions, etc, and then I
have all the methods that go with it for fetching, configuring,
building, resolving dependancies, etc, would it make more sense to keep
all those methods out of the class or leave them in the class, even
though it would make that class huge?
I realize it’s PROBABLY a matter of taste, but are there any good
reasons to do it one way or another?
Thanks for any input sent my way…
Jeremy
======= End of Original Message =======<
My personal sense would be to represent some of these ‘attributes’ as
members of their own class, i.e. have a Dependency class which you use
through composition. Your ‘Tarball’ class would then have a container of
‘Dependency’ objects (and so forth for other things which have a logical
grouping).
Should there be little in the Dependency class itself, and a lot more
methods that operate on dependencies, then perhaps you make a
DependencyHandler class to which all dependency classes are delegated.
I find that even if it starts real simple and you tell yourself ‘Nah, I
don’t need a class, I’ll just use a String/Hash/Array’, that eventually you
end up extending things you want to store and you at least want a Struct
for such a thing.
My personal taste suggests you should not make a module which can’t
usefully be mixed in to any other class than the one you have in mind.
You can even have several files, which all contain method definitions for
the one class, grouped by what they do In some ways I like that better
than a bunch of mixins.
But as you say, it is mostly a matter of taste
OT: Isn’t the biggest complaint right now about Gentoo’s portage speed?
It’s written in Python, but I think you might run into the same problem
with a similar implementation written in Ruby.
···
On Aug 21, Jeremy Whetzel wrote:
Hello all!
I’m planning on playing around with writing some sort of “package
manager” for source based Linux distros or any of the BSDs. I’m
thinking along the lines of Gentoo’s portage system or the BSD ports
system. I was toying around with modules with this idea, and I got
to wondering something. If a class needs a lot of different methods,
such as 30 or 40+ methods, and they’re all very specific to that class,
does it make sense to pull out a bunch of those methods and put them
into a module and mix them in later, or should they be kept in with the
class? For example, if I have an object that represents a software
tarball, and that object has a number of attributes such as
dependancies, reverse dependancies, comments, versions, etc, and then I
have all the methods that go with it for fetching, configuring,
building, resolving dependancies, etc, would it make more sense to keep
all those methods out of the class or leave them in the class, even
though it would make that class huge?
I realize it’s PROBABLY a matter of taste, but are there any good
reasons to do it one way or another?
Thanks for any input sent my way…
Jeremy
–
Brett Williams
[Damn this top-posting!]
The CGI class in the stdlib (lib/cgi.rb) has heaps and heaps of methods.
They are grouped into modules and mixed in. It seems a good way to do it
to me, because it gives you a tangible way of grouping that is good for
documentation. That assumes, of course, that you can justify so many
methods in the first place.
Some of the modules are explicitly justified because they are
conditionally mixed in. QueryExtensions and HttpExtensions are not like
this, however, and the user needn’t know they exist. It’s good from
RDoc’s point of view, though, because you don’t have to look at millions
of methods at once.
Gavin
···
I suppose it depends on what kind of methods they are - for example, I
was very confused when I went looking for the File.exists? method in the
File class only to find that it was part of the Filetest mixin. I
suppose that class methods like those can be defined in a module. It
seems that all instance methods should be explicitly members of the
class, though.
-Kurt
On Thu, Aug 21, 2003 at 01:32:38PM +0900, Jeremy Whetzel wrote:
Hello all!
I’m planning on playing around with writing some sort of “package
manager” for source based Linux distros or any of the BSDs. I’m
thinking along the lines of Gentoo’s portage system or the BSD ports
system. I was toying around with modules with this idea, and I got to
wondering something. If a class needs a lot of different methods, such
as 30 or 40+ methods, and they’re all very specific to that class,
does it make sense to pull out a bunch of those methods and put them
into a module and mix them in later, or should they be kept in with
the class? For example, if I have an object that represents a
software tarball, and that object has a number of attributes such as
dependancies, reverse dependancies, comments, versions, etc, and then
I have all the methods that go with it for fetching, configuring,
building, resolving dependancies, etc, would it make more sense to
keep all those methods out of the class or leave them in the class,
even though it would make that class huge?
I realize it’s PROBABLY a matter of taste, but are there any good
reasons to do it one way or another?
Thanks for any input sent my way…
Jeremy
======= End of Original Message =======<
For example, if I have an object that represents
a software tarball, and that object has a number of attributes such
as dependancies, reverse dependancies, comments, versions, etc, and
then I have all the methods that go with it for fetching,
configuring, building, resolving dependancies, etc, would it make
more sense to keep all those methods out of the class or leave them
in the class, even though it would make that class huge?
My personal sense would be to represent some of these ‘attributes’ as
members of their own class, i.e. have a Dependency class which you use
through composition. Your ‘Tarball’ class would then have a container
of’Dependency’ objects (and so forth for other things which have a
logical grouping).
I had thought of that, but I believe I chose poor wording in saying a
“tarball object”. I was thinking more specifically of having a"port"
class that has all those different attributes. The thing with making
the dependancies a seperate class is that they can also have
dependancies. Essentially they’re all ports requiring ports requiring
ports. They’re all kind of the same object.
My personal taste suggests you should not make a module which can’t
usefully be mixed in to any other class than the one you have in mind.
Understood, and I feel the same way. To me it just seemed kind of
awkward, although so did having a huge class with loads of methods…
You can even have several files, which all contain method definitions
for the one class, grouped by what they do In some ways I like
that better than a bunch of mixins.
I like this idea, too. Perhaps I’ll give it a shot.
OT: Isn’t the biggest complaint right now about Gentoo’s portage
speed? It’s written in Python, but I think you might run into the same
problem with a similar implementation written in Ruby.
This may be. I hadn’t actually used Gentoo’s portage system in quite a
while. I’ve been unable to get the darn thing to build on my system.
=0p But when I used it 6+ months ago, the speed of portage itself
seemed fine, especially comparing it to the time to download and build
stuff. g I’m just mainly doing this as a learning experience and for
benefit of myself while using FreeBSD.
Thanks,
Jeremy
···
On Thu, 21 Aug 2003 13:48:58 +0900 “Brett H. Williams” brett_williams@agilent.com wrote:
On Aug 21, Jeremy Whetzel wrote:
The CGI class in the stdlib (lib/cgi.rb) has heaps and heaps of
methods. They are grouped into modules and mixed in. It seems a good
way to do it to me, because it gives you a tangible way of grouping
that is good for documentation. That assumes, of course, that you can
justify so many methods in the first place.
Some of the modules are explicitly justified because they are
conditionally mixed in.
This is another idea I like a lot. I can see how this may help things
run a little quicker if I grouped things by function and only loaded
them when requested.
It’s good from RDoc’s point of view, though, because you don’t have
to look at millions of methods at once.
I haven’t messed around much with RDoc, but I can understand your point
on this one.
Thanks again!
Jeremy
···
On Thu, 21 Aug 2003 14:00:28 +0900 “Gavin Sinclair” gsinclair@soyabean.com.au wrote: