----- Original Message -----
> On Fri, Jan 7, 2011 at 1:41 PM, R.I.Pienaar < r...@devco.net > wrote:
>
>
> (forced to top post due to your html email)
>
> You cant avoid the scoping issues cos its broken. You can work around
> them though.
>
> You can be careful about where you set variables and how you include
> things. This
> isn't new we've been doing it for years.
>
> You can use extlookup to fetch variables from your data store in the
> class you need
> it and not rely on setting variables in one scope and accessing them
> in others.
>
> You can have some very simple syntax and style rules that says include
> classes first
> in your class then set variables to avoid the strange ordering issues.
>
>
> This is exactly what I have been recommending to people for variables.
>
> The problem is that you can't manage the scope binding stacks in the
> same way for resource defaults, or implicit tags.
>
> I think that making resource defaults behave like variables in this
> sense would go a long way to fixing the existing concerns with
> include.
>
> ie:
>
> in:
>
> class foo {
> include bar
> File{mode => 777}
> }
>
> This resource default in foo should not effect resources in bar
>
>
> You can create wrapper classes that include other classes but not set
> variables.
> class apache includes apache::config, ::install and ::service and as
> above in each
> case where you need to know apache version or something you can get
> that from extlookup
> which gives you configurable classes today without the scoping issues.
>
> By arranging modules like this - one class that exist only to include
> other classes -
> you totally avoid issues like setting defaults bleeding into other
> scopes. I have 100+
> modules and never even realized the defaults propagate over included
> classes because
> my coding style and standards simply doesnt allow that to happen.
>
> We've avoided these issues for years and the techniques are well
> known.
>
> Now when the language wish to get new features and improve itself you
> can either introduce
> a whole slew of new syntax, deprecate old syntax etc and new ways of
> writing manifests
> or you can fix the scoping problems which will result in existing
> techniques and language
> features working sanely?
>
>
> I agree with your point here about deprecating old features, but this
> is not the only advantage of param classes, the other is that it
> specifies a real interface:
>
> class foo(
> $bar, $baz, $bad
> ) {
> ...
> }
>
> is way better then:
>
> # this excepts bar,baz, and bad
> class foo{
> ...
> }
>
> I am not a big fan of extlookup for the same reason, it hides the
> interface for a class as opposed to exposing it. (although this does
> work better with dynamic scoping for reasons mentioned in this thread)
I totally agree and the new design for external variables - which I dont think
has been shared with the community for comment yet - is a good replacement for
extlookup last time I saw what was planned.
My issue is we're suggesting people write horrible code instead of teaching
them how to work around the scoping fail while we *fix the scoping fail*
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
