This is in reference to David Schmitt''s writeup [1]
I like that writeup a lot; I just had a few comments/clarifications:
* Namespaces: For now, we just use a flat namespace for modules, i.e.
you can''t have modules within modules, and you always know that in a
fully qualified name ''foo::bar::baz'' that
''foo'' is the module name and
''bar::baz'' is something defined within that module
(incidentally, I
wasn''t the one suggesting the ''.'' as a separator, I
am perfectly happy
with ''::'') We''ll deal with the pain of namespace
clashes when they
become an issue.
* Main module file: The Wiki page talks about modules having a
''MODULE_DIR/module_name/manifest.pp'' - shouldn''t that
file also go into
the manifests directory ? (And we might want to call it module.pp)
* Import/file name resolution: When puppet encounters a statement like
''import "foo"'' it first looks for a file
''MODULE_DIR/foo/manifests/module.pp'' - if no such file can be
found on
the MODULE_PATH, it looks for a file ''foo.pp'' in the
manifestdir.
Similarly for ''import "foo/bar/baz.pp"'': first look
for manifest
bar/baz.pp in a module ''foo'', then look for a file
''foo/bar/baz.pp'' in
the manifestdir.
Templates should be treated analogously with respect to MODULE_PATH and
templatedir.
* Includes: the example on the Wiki page use strings as the names for
includes; that shouldn''t be necessary, just ''include
foo::bar::baz''
should be legal syntax.
* Module naming in the language: should it be necessary to explicitly
set the module name (similar to Ruby) or should that always be implied
from the location in the filesystem (similar to Python), i.e.
''foo/manifests/bar.pp'' look something like
module foo {
class some_class {
...
}
}
class foo::other_class {
...
}
or should it just say
class bar {
...
}
I like having the namespace explicitly in the manifest (I am not too
hung up whether there should be a separate ''module'' keyword or
not), but
I''d like to hear if there is a strong argument to not include that.
* The Wiki says
Module names should contain a tag denoting the organisation to
be globally unique.
I don''t understand what is meant by that.
* We will probably need some module metadata fairly soon, in particular
a globally unique name for modules (I am thinking of just using a URL)
That metadata should probably go into a separate file; any strong
arguments for embedding that metadata in the manifest ?
At some point, there''s also going to be a need to include dependency
information in the module metadata (module webserver needs module
funky_yumrepos), though that would probably not affect puppet itself,
just the tool downloading modules, like prm.
* My previous writeup at [2] should probably die; I''ll delete the page
in a few days
David
[1] http://reductivelabs.com/cgi-bin/puppet.cgi/wiki/ModuleOrganisation
[2] http://reductivelabs.com/cgi-bin/puppet.cgi/wiki/ModuleOrganisation
On Feb 9, 2007, at 2:18 PM, David Lutterkort wrote:> This is in reference to David Schmitt''s writeup [1] > > I like that writeup a lot; I just had a few comments/clarifications:I completely agree with this whole document, and I would be fine shipping it just as soon as you''re done. :)> * Main module file: The Wiki page talks about modules having a > ''MODULE_DIR/module_name/manifest.pp'' - shouldn''t that file also go > into > the manifests directory ? (And we might want to call it module.pp)Good idea; I like the file being inside the directory, rather than outside like it is with Ruby. I might argue for init.pp just because that''s what the python guys do (why add arbitrary difference?), but eh.> I like having the namespace explicitly in the manifest (I am not too > hung up whether there should be a separate ''module'' keyword or > not), but > I''d like to hear if there is a strong argument to not include that.I''ve always felt like it''s intuitive that file paths should equate to namespace, but the lack of adoption of this implies otherwise. My tendency would be for that, but I expect my intuition is not the majority. We should not introduce a new module keyword; just use: class foo::baz { ... }> * We will probably need some module metadata fairly soon, in > particular > a globally unique name for modules (I am thinking of just using a URL) > That metadata should probably go into a separate file; any strong > arguments for embedding that metadata in the manifest ? > > At some point, there''s also going to be a need to include dependency > information in the module metadata (module webserver needs module > funky_yumrepos), though that would probably not affect puppet itself, > just the tool downloading modules, like prm.I''d say all metadata should go in the packaging system, not in the module system. Let the PRM guys solve those problems. :) -- Never interrupt your enemy when he is making a mistake. --Napolean Bonaparte --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 09 February 2007 21:18, David Lutterkort wrote:> This is in reference to David Schmitt''s writeup [1] > > I like that writeup a lot; I just had a few comments/clarifications:Thank you for your insightful comments, I tried to incorporate them into the page and restructured it a bit.> * Main module file: The Wiki page talks about modules having a > ''MODULE_DIR/module_name/manifest.pp'' - shouldn''t that file also go into > the manifests directory ? (And we might want to call it module.pp)It seemed like a good idea when I wrote it. I replaced it by a convetional .pp file, which is named after the module. Together with the search mechanisms, it enables the simple "import module_name" to work as expected.> * Import/file name resolution: When puppet encounters a statement like > ''import "foo"'' it first looks for a file > ''MODULE_DIR/foo/manifests/module.pp'' - if no such file can be found on > the MODULE_PATH, it looks for a file ''foo.pp'' in the manifestdir.I tried to formalize that a bit on the wiki page, could you perhaps take a second look and propose/effect improvements if neccessary?> * Module naming in the language: should it be necessary to explicitly > set the module name (similar to Ruby) or should that always be implied > from the location in the filesystem (similar to Python), i.e.[snip]> I like having the namespace explicitly in the manifest (I am not too > hung up whether there should be a separate ''module'' keyword or not), but > I''d like to hear if there is a strong argument to not include that.That probably depends whether the module_name becomes part of the class name or whether you see it only as a disambiguation help for the parser. I think that the module_name is only "decoration" and should never be used inside the module itself. Looking at the StanfordPuppetBestPractices document, I see that they have separate directories for defines, classes, os, services and various other stuff, where I don''t think it would make much sense to also have this distinction also on definition-name level. Perhaps someone from Stanford can comment on that?> * The Wiki says > Module names should contain a tag denoting the organisation to > be globally unique. > I don''t understand what is meant by that.I have clarified that as follows: Naming - ------ To reduce the risk of module name clashes, entities releasing puppet modules are encouraged to prefix module names with a short tag denoting their organisation (e.g. ``labs_defaultconfig``, ``stanfords_something_classes`` and similar).> * We will probably need some module metadata fairly soon, in particular > a globally unique name for modules (I am thinking of just using a URL) > That metadata should probably go into a separate file; any strong > arguments for embedding that metadata in the manifest ?As Luke said, metadata should stay outside. Especially since one can use really simple rfc822 style paragraphs like debian does for describing packages.> * My previous writeup at [2] should probably die; I''ll delete the page > in a few days> [1] http://reductivelabs.com/cgi-bin/puppet.cgi/wiki/ModuleOrganisation > [2] http://reductivelabs.com/cgi-bin/puppet.cgi/wiki/ModuleOrganisationWhich URL did you mean? Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFz8L9/Pp1N6Uzh0URAvwcAJ9qV8Z7Q1Et/fAsZXk2e9CjBUOtiwCfezLk FiJIPMdPodFfxYf64ruGSwo=gz+k -----END PGP SIGNATURE-----
On Feb 11, 2007, at 7:29 PM, David Schmitt wrote:> > It seemed like a good idea when I wrote it. I replaced it by a > convetional .pp > file, which is named after the module. Together with the search > mechanisms, > it enables the simple "import module_name" to work as expected.I kind of like having a standard name for the intro file, rather than naming it after the module (e.g., init.pp or module.pp), but I don''t feel particularly strongly about it. It would make it a touch easier to search for modules, though (i.e., you''d be looking for $module/ manifests/module.pp instead of $module/manifests/$module.pp; thus, one variable instead of two).>> * Import/file name resolution: When puppet encounters a statement >> like >> ''import "foo"'' it first looks for a file >> ''MODULE_DIR/foo/manifests/module.pp'' - if no such file can be >> found on >> the MODULE_PATH, it looks for a file ''foo.pp'' in the manifestdir. > > I tried to formalize that a bit on the wiki page, could you perhaps > take a > second look and propose/effect improvements if neccessary?It looks fine, IMO.>> * Module naming in the language: should it be necessary to explicitly >> set the module name (similar to Ruby) or should that always be >> implied >> from the location in the filesystem (similar to Python), i.e. > [snip] >> I like having the namespace explicitly in the manifest (I am not too >> hung up whether there should be a separate ''module'' keyword or >> not), but >> I''d like to hear if there is a strong argument to not include that. > > That probably depends whether the module_name becomes part of the > class name > or whether you see it only as a disambiguation help for the parser. > I think > that the module_name is only "decoration" and should never be used > inside the > module itself. Looking at the StanfordPuppetBestPractices document, > I see > that they have separate directories for defines, classes, os, > services and > various other stuff, where I don''t think it would make much sense > to also > have this distinction also on definition-name level. Perhaps > someone from > Stanford can comment on that?I would say that in general all classes and definitions defined inside a module should be scoped to that module; e.g., you''d create mystuff::remotefile, not remotefile. This means we''ll have to introduce a function similar to ruby''s "include" that add''s a given module''s class to another class''s search path. E.g., if we ship ''remotefile'' as part of Puppet (which should probably happen at some point), then it might be named ''puppet::remotefile'' or something, and you could add ''puppet'' to a class''s search path such that you could use ''remotefile'' unqualified.>> * The Wiki says >> Module names should contain a tag denoting the >> organisation to >> be globally unique. >> I don''t understand what is meant by that. > > I have clarified that as follows: > > Naming > - ------ > > To reduce the risk of module name clashes, entities releasing > puppet modules > are encouraged to prefix module names with a short tag denoting their > organisation (e.g. ``labs_defaultconfig``, > ``stanfords_something_classes`` > and similar).I don''t really like this idea; either your module is generically useful, so it doesn''t need a tag, or it''s not, so it maybe shouldn''t be published. If tags like that are needed, we should just support heirarchical modules (e.g., stanford/something). -- When a man tells you that he got rich through hard work, ask him: ''Whose?'' --Don Marquis --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 12 February 2007 04:09, Luke Kanies wrote:> On Feb 11, 2007, at 7:29 PM, David Schmitt wrote: > >> * Module naming in the language: should it be necessary to explicitly > >> set the module name (similar to Ruby) or should that always be > >> implied > >> from the location in the filesystem (similar to Python), i.e. > > > > [snip] > > > >> I like having the namespace explicitly in the manifest (I am not too > >> hung up whether there should be a separate ''module'' keyword or > >> not), but > >> I''d like to hear if there is a strong argument to not include that. > > > > That probably depends whether the module_name becomes part of the > > class name > > or whether you see it only as a disambiguation help for the parser. > > I think > > that the module_name is only "decoration" and should never be used > > inside the > > module itself. Looking at the StanfordPuppetBestPractices document, > > I see > > that they have separate directories for defines, classes, os, > > services and > > various other stuff, where I don''t think it would make much sense > > to also > > have this distinction also on definition-name level. Perhaps > > someone from > > Stanford can comment on that? > > I would say that in general all classes and definitions defined > inside a module should be scoped to that module; e.g., you''d create > mystuff::remotefile, not remotefile. > > This means we''ll have to introduce a function similar to ruby''s > "include" that add''s a given module''s class to another class''s search > path. > > E.g., if we ship ''remotefile'' as part of Puppet (which should > probably happen at some point), then it might be named > ''puppet::remotefile'' or something, and you could add ''puppet'' to a > class''s search path such that you could use ''remotefile'' unqualified.The wiki page is currently written under the assumption that all imported namespaces will be on the search path by default and only unqualified AND ambiguous references are an error. The last is very important: for example the shell PATH doesn''t have this safety and once I did forget a custom compiled something in /usr/local/bin and embarrassed myself by filing a bogus bug against the tool.> I kind of like having a standard name for the intro file, rather than > naming it after the module (e.g., init.pp or module.pp), but I don''t > feel particularly strongly about it. It would make it a touch easier > to search for modules, though (i.e., you''d be looking for $module/ > manifests/module.pp instead of $module/manifests/$module.pp; thus, > one variable instead of two).Under the assumption that puppet should do "the right thing" on "import module_name", $module/manifests/$module.pp is found by a appropriate search path implementation by default, since it looks for ''manifests/module_name.pp'' in all modules on the MODULE_PATH. For a manifests/module.pp, "import module_name" really has to do a custom lookup, but it saves one search through all modules.> >> * The Wiki says > >> Module names should contain a tag denoting the > >> organisation to > >> be globally unique. > >> I don''t understand what is meant by that. > > > > I have clarified that as follows: > > > > Naming > > - ------ > > > > To reduce the risk of module name clashes, entities releasing > > puppet modules > > are encouraged to prefix module names with a short tag denoting their > > organisation (e.g. ``labs_defaultconfig``, > > ``stanfords_something_classes`` > > and similar). > > I don''t really like this idea; either your module is generically > useful, so it doesn''t need a tag, or it''s not, so it maybe shouldn''t > be published. > > If tags like that are needed, we should just support heirarchical > modules (e.g., stanford/something).I see your point. Not recommending that implies aggressive efforts to provide "best practice" implementations for many common scenarios to reduce the possibility of hundreds of differing "debian" (or "redhat" or ...) modules floating around. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF0HkT/Pp1N6Uzh0URAmdKAJkB9C7LV+aVcCvfhWKcAqZ67r09QgCfWNlE fDe7uizx+DErtWRrS9rf8as=kmPA -----END PGP SIGNATURE-----
On Feb 12, 2007, at 8:26 AM, David Schmitt wrote:>> E.g., if we ship ''remotefile'' as part of Puppet (which should >> probably happen at some point), then it might be named >> ''puppet::remotefile'' or something, and you could add ''puppet'' to a >> class''s search path such that you could use ''remotefile'' unqualified. > > The wiki page is currently written under the assumption that all > imported > namespaces will be on the search path by default and only > unqualified AND > ambiguous references are an error. The last is very important: for > example > the shell PATH doesn''t have this safety and once I did forget a custom > compiled something in /usr/local/bin and embarrassed myself by > filing a bogus > bug against the tool.I''m pretty sure you wouldn''t want this in most cases. I understand what you''re saying about it being annoying having to fully qualify by default, but I think that''s the only reasonable default in this kind of case.> Under the assumption that puppet should do "the right thing" on > "import > module_name", $module/manifests/$module.pp is found by a > appropriate search > path implementation by default, since it looks for ''manifests/ > module_name.pp'' > in all modules on the MODULE_PATH. For a manifests/module.pp, "import > module_name" really has to do a custom lookup, but it saves one search > through all modules.I still don''t like the duplication of the module name here, both in the path and the main file. What do others thing?>> I don''t really like this idea; either your module is generically >> useful, so it doesn''t need a tag, or it''s not, so it maybe shouldn''t >> be published. >> >> If tags like that are needed, we should just support heirarchical >> modules (e.g., stanford/something). > > I see your point. Not recommending that implies aggressive efforts to > provide "best practice" implementations for many common scenarios > to reduce > the possibility of hundreds of differing "debian" (or "redhat" or ...) > modules floating around.It''s partially that -- encouraging submission of more stable modules -- but mostly just that if you do this you''re encoding more than one type of data into the module name, which always bites you in the end, in my experience. -- As a general rule, don''t solve puzzles that open portals to Hell. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Mon, 2007-02-12 at 02:29 +0100, David Schmitt wrote:> On Friday 09 February 2007 21:18, David Lutterkort wrote: > > This is in reference to David Schmitt''s writeup [1] > > > > I like that writeup a lot; I just had a few comments/clarifications: > > Thank you for your insightful comments, I tried to incorporate them into the > page and restructured it a bit.Cool, thanks - I made some small cosmetic changes to the doc.> > * Import/file name resolution: When puppet encounters a statement like > > ''import "foo"'' it first looks for a file > > ''MODULE_DIR/foo/manifests/module.pp'' - if no such file can be found on > > the MODULE_PATH, it looks for a file ''foo.pp'' in the manifestdir. > > I tried to formalize that a bit on the wiki page, could you perhaps take a > second look and propose/effect improvements if neccessary?The current writeup on the Wiki implies that there is some awareness which module you are currently in - that makes things less transparent and makes it harder to figure out which file exactly gets imported by an ''import "foo.pp"'' I would much rather stick to what I proposed in my original mail, a naming scheme that does not require awareness of an implicit module context. In other words, what happens when you write import "foo/bar.pp" does not depend on whether that statement is in your site.pp, the main module file for the foo module, or in another module. The search strategy I outlined would give you predictable behavior, and you could still easily make ''import "foo"'' go to the main module file for the foo module.> That probably depends whether the module_name becomes part of the class name > or whether you see it only as a disambiguation help for the parser. I think > that the module_name is only "decoration" and should never be used inside the > module itself.I would hugely prefer explicit naming, since IMHO it makes reading code much easier. That doesn''t mean that there can''t be constracts to set the default namespace (like a ''module'' keyword) or import a modules names into the currant namespace (like ruby''s include) - it just means that that should be explicit.> > [1] http://reductivelabs.com/cgi-bin/puppet.cgi/wiki/ModuleOrganisation > > [2] http://reductivelabs.com/cgi-bin/puppet.cgi/wiki/ModuleOrganisation > > Which URL did you mean?Heh, sorry .. http://reductivelabs.com/cgi-bin/puppet.cgi/wiki/MasterConfigLayout David
On Fri, 2007-02-09 at 17:05 -0600, Luke Kanies wrote:> On Feb 9, 2007, at 2:18 PM, David Lutterkort wrote: > > > This is in reference to David Schmitt''s writeup [1] > > > > I like that writeup a lot; I just had a few comments/clarifications: > > I completely agree with this whole document, and I would be fine > shipping it just as soon as you''re done. :)Heh .. give me another 20 minutes ;) Seriously, I''ll try and get to it next week.> Good idea; I like the file being inside the directory, rather than > outside like it is with Ruby. I might argue for init.pp just because > that''s what the python guys do (why add arbitrary difference?), but eh.Yeah, I prefer a manifests/init.pp for that purpose.> We should not introduce a new module keyword; just use: > > class foo::baz { ... }Definitely the simplest way; and we can always revisit that if typing module names becomes too onerous.> > At some point, there''s also going to be a need to include dependency > > information in the module metadata (module webserver needs module > > funky_yumrepos), though that would probably not affect puppet itself, > > just the tool downloading modules, like prm. > > I''d say all metadata should go in the packaging system, not in the > module system. Let the PRM guys solve those problems. :)Hehe .. I agree with that sentiment though. After I wrote my initial mail, it hit me that I had just proposed yet another packaging system with dependencies and all - not sure if I really want to go down that path. Maybe just relying on native package managers (rpm, dpkg, ...) is good enough for now. Which brings up another point: the reason prm used mercurial for recipe distribution was mostly based on the belief that people would have to change downloaded recipes for their site by editing the files in the recipe directly. Now, I wonder if that is really needed or if the same couldn''t always be achieved by subclassing, so that downloaded recipes/modules will never be changed by a site. Any thoughts on this aspect ? David
On Mon, 2007-02-12 at 15:26 +0100, David Schmitt wrote:> > > To reduce the risk of module name clashes, entities releasing > > > puppet modules > > > are encouraged to prefix module names with a short tag denoting their > > > organisation (e.g. ``labs_defaultconfig``, > > > ``stanfords_something_classes`` > > > and similar). > > > > I don''t really like this idea; either your module is generically > > useful, so it doesn''t need a tag, or it''s not, so it maybe shouldn''t > > be published. > > > > If tags like that are needed, we should just support heirarchical > > modules (e.g., stanford/something). > > I see your point. Not recommending that implies aggressive efforts to > provide "best practice" implementations for many common scenarios to reduce > the possibility of hundreds of differing "debian" (or "redhat" or ...) > modules floating around.Oh, how I would love to have these problems ;) Until we actually have problems with name clashes, I suggest we just ignore the problem. David
On Feb 12, 2007, at 3:07 PM, David Lutterkort wrote:> > Oh, how I would love to have these problems ;) Until we actually have > problems with name clashes, I suggest we just ignore the problem.I concur. -- Never try to tell everything you know. It may take too short a time. --Norman Ford --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Feb 12, 2007, at 3:06 PM, David Lutterkort wrote:> On Fri, 2007-02-09 at 17:05 -0600, Luke Kanies wrote: >> >> I completely agree with this whole document, and I would be fine >> shipping it just as soon as you''re done. :) > > Heh .. give me another 20 minutes ;) Seriously, I''ll try and get to it > next week.Seriously, I think it''s going to be a ton of work (the implementation, not the document, which is what I meant), but it''d be great if you''d do it. :)>> Good idea; I like the file being inside the directory, rather than >> outside like it is with Ruby. I might argue for init.pp just because >> that''s what the python guys do (why add arbitrary difference?), >> but eh. > > Yeah, I prefer a manifests/init.pp for that purpose.Let''s do that, then.>>> At some point, there''s also going to be a need to include dependency >>> information in the module metadata (module webserver needs module >>> funky_yumrepos), though that would probably not affect puppet >>> itself, >>> just the tool downloading modules, like prm. >> >> I''d say all metadata should go in the packaging system, not in the >> module system. Let the PRM guys solve those problems. :) > > Hehe .. I agree with that sentiment though. After I wrote my initial > mail, it hit me that I had just proposed yet another packaging system > with dependencies and all - not sure if I really want to go down that > path. Maybe just relying on native package managers (rpm, > dpkg, ...) is > good enough for now.I think so.> Which brings up another point: the reason prm used mercurial for > recipe > distribution was mostly based on the belief that people would have to > change downloaded recipes for their site by editing the files in the > recipe directly. Now, I wonder if that is really needed or if the same > couldn''t always be achieved by subclassing, so that downloaded > recipes/modules will never be changed by a site. Any thoughts on this > aspect ?I think that should be in a separate PRM thread, which needs some of its own loving these days, but I don''t currently have the bandwidth for it. -- I take my children everywhere, but they always find their way back home. --Robert Orben --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 12 February 2007 22:07, David Lutterkort wrote:> Oh, how I would love to have these problems ;) Until we actually have > problems with name clashes, I suggest we just ignore the problem.Hehe. True. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF0XFr/Pp1N6Uzh0URApnRAJ4py/E7ogKTxvEv0f2eli/lNnsx7QCdHiyc lQJeLPS+0exDyTizzHu2BXo=xBpb -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 12 February 2007 21:58, David Lutterkort wrote:> > > * Import/file name resolution: When puppet encounters a statement like > > > ''import "foo"'' it first looks for a file > > > ''MODULE_DIR/foo/manifests/module.pp'' - if no such file can be found on > > > the MODULE_PATH, it looks for a file ''foo.pp'' in the manifestdir. > > > > I tried to formalize that a bit on the wiki page, could you perhaps take > > a second look and propose/effect improvements if neccessary? > > The current writeup on the Wiki implies that there is some awareness > which module you are currently in - that makes things less transparent > and makes it harder to figure out which file exactly gets imported by an > ''import "foo.pp"'' > > I would much rather stick to what I proposed in my original mail, a > naming scheme that does not require awareness of an implicit module > context. In other words, what happens when you write > import "foo/bar.pp" > does not depend on whether that statement is in your site.pp, the main > module file for the foo module, or in another module. > > The search strategy I outlined would give you predictable behavior, and > you could still easily make ''import "foo"'' go to the main module file > for the foo module. > > > That probably depends whether the module_name becomes part of the class > > name or whether you see it only as a disambiguation help for the parser. > > I think that the module_name is only "decoration" and should never be > > used inside the module itself. > > I would hugely prefer explicit naming, since IMHO it makes reading code > much easier. That doesn''t mean that there can''t be constracts to set the > default namespace (like a ''module'' keyword) or import a modules names > into the currant namespace (like ruby''s include) - it just means that > that should be explicit.Hmmm, personally I''m leaning more toward a concise style. I have to acknowledge though, that this is not optimal for everyone. Can we agree to disagree on this point? Just write up the alternative proposal and put it on the page. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF0XO+/Pp1N6Uzh0URAjEmAJ9EouZGVWOSSdUPYycrXHoYmFKOswCghZyI KtWBssg8m+EwsFHsPP09R+E=SzAN -----END PGP SIGNATURE-----