-- Erik Dalén
On Wednesday 10 April 2013 at 11:48, Henrik Lindberg wrote: > On 2013-08-04 16:17, Keith Burdis wrote: > > On 8 April 2013 12:31, Erik Dalén <[email protected] > > (mailto:[email protected]) > > <mailto:[email protected]>> 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. That sounds like it could work for resources. But what about referencing a variable across modules? They don't create any catalog entry AFAIK. But I guess scope objects could be shared. > > 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 [email protected] > > (mailto:[email protected]). > > To post to this group, send email to [email protected] > > (mailto:[email protected]). > > 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 [email protected] > (mailto:[email protected]). > To post to this group, send email to [email protected] > (mailto:[email protected]). > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
