----- Original Message -----
> > In this example that you are responding to - class php::foo that
> > requires php -
> > your suggestion is a bit weird. With your suggestion anyone who ever
> > want to
> > use this class need to know "when including php::foo you need to
> > remember to
> > set the requirement on foo" when in fact what you want is to include
> > the foo::bar
> > class and it should just behave in a sane way without any burden of
> > documentation
> > or everyone using it creating the dependencies tree.
>
> I was perhaps too terse in my response here: generally I would expect
> that to happen *inside* the php::foo class, so that 'include php::foo'
> would do the right thing on the node:
>
> class foo { ... }
> class bar {
> include foo
> package { "whatever": require => Class["foo"] }
> }
>
> Then 'include bar' will just work⢠for end users, including the
> appropriate cross-class dependencies and inclusions. Which still
> fails if foo is parameterized, but that is ... a rough area right now.
imho the right solution is a combination of the require and include keywords,
resources requiring classes used extremely sparingly and the new syntax as Dan
pointed out.
What worries me greatly is that 'use parametrized classes' for everything
recommendation seems to be the default response these days from PL even to the
point of suggesting the include and require keywords be removed and deprecated
while the alternatives are, to be frank, half baked.
It spreads confusion and frustrates users.
At Puppet Camp in the US it was clear the impression by many were that the
Language
has gone a bit in the wrong direction use case wise and Luke suggested that a
community +
puppet labs panel will be formed to help decide how the language gets designed
rather than
it be just a bunch of features that kind of works together. I'd very much like
to see
this happen and I believe it's becoming pretty desperately needed :)
The DSL used to exist as a simple language that does what we do elegantly and
in a
well designed manner. In a way that systems administrators can understand and
embrace.
A language that obvious how it behaves when looked at and the outcome and
behavior
of code is clear. These were the reasons it is touted over using a turing
complete
programming language.
What we have today is a language with special meaning in the following symbols:
=>, <|, |>, <||, ||>, @, @@, +=, ->, =>, <-, <=, ~>, <~
I'd wager that you couldn't find more than 20 community members who can explain
without
referencing documentation what each of these do. And more importantly when
speaking to
the ones who know you'll in almost all cases be told of edge cases, strange
interactions
and odd bugs in these when used alone or in combination with others.
We have unpredictable inconsistencies where a case statement is case
insensitive except
when you use regular expressions, then its case sensitive. And many more
similar issues,
issues that have us essentially sit with small test.pp scripts and learn by
observation
how things work constantly expecting the behavior that most people might find
most
surprising would be the one that you'll find in complex use cases. Worse these
inconsistancies change in new weird and interesting ways between versions. At
this point
using a real language would be more bearable.
General usage, user friendliness and consistency should become a big priority
with how a
feature would be used and how it would interact with existing code and coding
style should
matter greatly.
Thus I'd like to see the above mentioned language steering group to be put
together so that
the people who use the language can get real input into how it evolves.
--
R.I.Pienaar
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" 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-users?hl=en.
