On Wed, Oct 13, 2010 at 1:49 AM, Peter Meier <[email protected]> wrote:
> > It is currently legal to do
> >
> > class A {
> > class disable inherits A {
> > ...
> > }
> > }
> >
> > and then "include A::disable".
>
> It is also legal (and imho the better way) to put the disable class in
> its own file. As far as I remember this doesn't make any difference,
> except using more inodes (as once somebody nagged on IRC).
>
> Anyway related to that discussion I might want to remember the other
> thread about autoloading where afair it was more or less consensus to
> enforce the policy that there should be only one class or define in a
> file corresponding to its name. So if we would do these
> autolookup/loading improvements (mainly perfomance) we would anyway get
> rid off that nested classes syntax. right?
>
I went back and re-read the thread about autoloading (
http://groups.google.com/group/puppet-dev/browse_thread/thread/2228455628cf083c/7aa89c325721fe08),
and my understanding of the consensus was different: I thought we decided
that we would prohibit files from containing classes that were unrelated to
the filename, but we would still permit nesting and multiple classes per
file. So, for instance, a file foo.pp would be allowed to contain "class
foo { }" or "class foo::bar { }" or even "class foo { class bar { } }", but
not "class bar { }".
IMHO enforcing one-class-per-file would be a big restriction to add, and
wouldn't gain us much benefit--it wouldn't fix bugs or clarify complex
semantics the way removing dynamic scoping would. Am I misreading the
consensus? If so, we should probably take further discussion back to that
thread to clear it up.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
