On Nov 30, 2008, at 2:43 PM, Florian Grandel wrote:
>
> 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.
Ah, that's right. I asked again because implementation often provides
key information on the complexity of an idea, and I think it would in
this case.
>
>> 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.
This is the same problem that convinced me to remove exactly this
syntax a couple of years ago.
>
> 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.
The problem doesn't really change if you switch to your concept of
bundles, as far as I can see.
>
>> 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?
Okay. At the least, I think this conversation has gone as far as it
can without implementation, so until someone has the cycles to start
developing this, there's not much point in continuing.
I'll continue trying to come up with a workable way of solving the
class parameter problem, and if I do, I'll get it implemented.
--
Smoking is one of the leading causes of statistics. -- Fletcher Knebel
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
