Hi Luke,
> Could you produce patches that provided
> what you want?
No, unfortunately not. I am currently working on other projects that
have priority. I wrote that in my first post to not deceive you
afterwards.
> class { webserver: ipaddress => "..." }
>
> So I'm ok with your basic request, but I don't see it as a complete
> syntactical proposal yet.
The syntax I proposed for "class instantiation" was:
webserver { ipaddress => "..." }
Or maybe
include webserver { ipaddress => "..." }
to keep backwards compatibility.
Class definition would be:
class webserver ($ipaddress) {...}
This syntax doesn't clash with functions, does it?
The difficulty I see is that classes included at several places "count"
only once. So this causes problems here because you could have the same
class included twice with different parameters.
To me this doesn't matter as I never include the same class twice. But
others probably want to continue being able to do so.
I only see the following options:
1) You throw an exception if the parameters for two includes of the same
class are not the same at runtime.
2) You "preconfigure" classes once with the above syntax somewhere in
global context and then include them without repeating the parameters
wherever you like.
I don't like either of the solutions very much. But that probably has
more to do with the fact that I find puppet's concept of classes
"difficult". So if one of the above two solutions is in line with the
current concept of classes then I'd implement it that way.
> You've syntactical confusion here, though -- Puppet's current parser
> would assume these are functions, not classes. You could try to
> autodetect the difference, but I think that would be much worse.
Well this can be easily resolved by requiring () for functions and
something like a "new" keyword for the instantiation of "bundles". I
certainly won't have to prove OO conceptual or practical viability. To
me it is more a matter of conviction to get puppet closer to a simple
and restricted OO language than a technical problem.
I have found workarounds and conventions for doing most of the things I
propose in puppet's current syntax here and now. I am "abusing" some
puppet concepts a little to get there but I get an easier to maintain
system in return. So there is no doubt that what I am proposing works
for me.
It all comes down to one question: Does "pure" OO provide a "better"
framework to represent configured resources or not?
If I have not convinced you by now I won't be able to do so in further
posts. I can't add any new arguments. I am just repeating myself. This
is not helpful.
To me this discussion was useful to consolidate my thoughts. I am using
puppet quite differently now. I hope that you got something out of it as
well. Maybe we should just leave it that way to not further waste your time?
Florian
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
