On Aug 20, 2006, at 11:10 AM, (e-mail address removed) wrote:=
first off, thanks for the article - i know this stuff is hard to write
about...
few questions/comments:
- Why I dynamically generate
can you give a little more context for the code shown:
package { ssh: ensure => installed, type => apt }
is this statement part of a dsl?
Yes, it is; I've got a grammar and everything for it. Before
everyone asks why I don't just use a Ruby DSL, please see http://
reductivelabs.com/projects/puppet/faq.html. I've actually toyed
recently with creating a Ruby DSL, just to see what it would look
like, and I think it would be at least as difficult, if not more so,
because of how differently Puppet defines classes vs. Ruby.
- Avoiding the inherited method
have you used delayed initialization like so:
harp:~ > cat a.rb [...]
i'm curious because i've faced this issue many times before too...
I had code that was similar. In thinking about the article after I
wrote it, avoiding the 'inherited' method did make my life much
easier but what really simplified my code were the class methods to
create new, related classes. As I mentioned in my article, most of
my classes are referenced by name, and having class creation happen
in a way that inherently handles class naming and class relationships
is much, much easier. Calling 'newclass' on the containing class is
much easier than creating the two classes and then marking them
related somehow.
I think that if I tended to refer to these classes by their constants
(i.e., their Ruby names) rather than by a human name, or if the
dynamic classes weren't always specifically associated with some kind
of containing class, the delayed initialization mechanism would work
pretty well. As it is, I've had multiple compliments on how nice
this class creation mechanism is, and it really was striking how much
better it made my life when I made this change. Also, your code
wouldn't work for me because the class's @name is often unrelated to
the constant -- I would need to use an array to store the subclasses
initially, and then hash after initialization.
I will say, though, that the mechanism I'm using provides a bit more
functionality than delayed initialization -- I can easily control
what happens at class creation time, before the block runs, and after
the block runs, and it wouldn't take much to add hooks for more class
customization if a specific class container needed it. As Why
pointed out in his metaprogramming article, it's always easier when
your code makes the metaprogramming explicit -- I seem to often start
out using 'inherited', but the code always gets cleaner when I move
away from it. I expect that your example code could be moved into a
module or something so that it made the metaprogramming explicit; it
would be interesting to compare the results of that with the system I
have. As I mentioned I'm using this class generation facility in
about 8 different places in Puppet -- I clearly would not wnat to
duplicate your code in all 8 of these places.
- i'm curious if the generated objects really need to be classes?
what i mean
is are there instances created later? the reason i ask is that
i've been
playing with prototypes lately and wondering if that might be
applicable to
this kind of problem
http://www.codeforpeople.com/lib/ruby/prototype/prototype-0.2.0/
README
Yes, instances of these classes are created. The refactoring that I
asked about earlier this week (transactions and idempotency) might
result in this no longer being the case for some of these classes, in
which case prototypes would be much simpler and in some cases could
provide more functionality.
