On Thu, Jan 6, 2011 at 3:14 PM, R.I.Pienaar <[email protected]> wrote:
>
>
> ----- 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
I am a HUGE fan of param classes;) I find the dynamic scoping implications
of include to be frightening and difficult to fully understand.
> 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.
>
I agree that we cannot deprecate include until we fully consider the
functionality that it provides and provide suitable work-arounds, I am also
a little concerned about backwards compatibility, I hope we never pull a
cfengine2->3
The only two that I can think of are:
- the ability to indicate a requirement for a class (all places that
require a class can include it)
- although the behavior this provides seems convenient, all of the
implications with dynamic scoping and the fact that only a single inclusion
path is chosen tp build the scope binding stacks based on code evaluation
order makes it hard to fully understand from code the true implications of
this
- the ability to ensure that a scope has been evaluated so that we can
access variables
are there others?
I consider deprecating require moot, b/c we can express it as
Class['self']->Class['other'] (unless there is something that I don't
understand about require?)
There still could be performance issues that need to be sorted out with this
approach.
It is a little concerning that the include -> param classes move does
require some rethinking about how to model things in Puppet, after having
gone though quite a bit of this, I am sure it is all for the best.
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.
I think you could break these into:
the ones everyone should know and advanced (<|, |>, <||, ||>, @, @@)
> 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.
>
I agree that we should identify which interactions and bugs exist and get
them prioritized. Maybe we could put together a list for consensus (I have a
few that come to mind)?
>
> We have unpredictable inconsistencies where a case statement is case
> insensitive except
> when you use regular expressions, then its case sensitive.
:(, you can make regex case insensitive in puppet with (?i-mx:regex)
> 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.
>
+1
I'm in
> --
> 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]<puppet-users%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
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.
