On 2013-08-04 16:17, Keith Burdis wrote:
On 8 April 2013 12:31, Erik Dalén <erik.gustav.da...@gmail.com
<mailto:erik.gustav.da...@gmail.com>> wrote:
On Friday 5 April 2013 at 20:26, henrik lindberg wrote:
...
> I hope we can correct the fundamental ones in the Puppet 4.0
evaluator
> (there are smells around undef, possibility to alter immutable
collections, around certain comparisons, and a few more corner cases
- i.e. things that are difficult/impossible to support more than one
way at the same time).
This sounds very good. Might be better having a global change to all
these behaviours than a configuration switch for each one of them.
Perhaps this could work in a similar way to the Perl 'use strict' pragma
where you can turn on all the strict checks or just the ones you want
(eg. 'use strict vars') and turn off the ones you don't want (eg. 'no
strict refs').
The idea is to have one "compliance level" that defines the expected
behavior of both the language and evaluator.
(In addition to this I imagine having switches that can turn things
on/off for experiments / debugging etc. but I am not sure what is useful
to have yet...)
> This work makes it possible for different modules to use
different compliance levels! It is only the fundamentals that must
be the same across all versions. To me this is perhaps the most
important goal. Going forward it is unreasonable to expect that all
forge modules must be updated at the same time in order for a user
to adopt a newer version of puppet.
How would that work? Should you specify the parser and evaluator to
use (or language version) in your Modulefile? Seems hard to me
technically to share state between multiple versions of the evaluator.
I expect this would have to be as lenient as required to parse and
evaluate all modules that are loaded, probably with a cache so this
doesn't have to be determined every time.
Code passes through the lexer and parser, and is then evaluated (some is
lazily evaluated; i.e. it is just registered, and evaluated on demand).
The result is entries in the catalog. It is that chain where I see that
the catalog can be shared across compliance levels.
A module would specify its compliance level. All loaded code knows where
it comes from, and hence all created things knows where they came from,
and hence they know which compliance level should be used to operate on
them. (I have a somewhat working implementation of parts of this doing
type loading of types described using puppet logic. This implementation
is very similar to how OSGi works for Java (given any object you can
find its classloader, classloaders are composed). Have not yet started
looking at Resource and Catalog and the logic around that to achieve the
final goal - next up is the evaluator, and the step after that is the
catalog.
Regards
- henrik
--
Erik Dalén
- Keith
--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-dev+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
