-- 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 <erik.gustav.da...@gmail.com > > (mailto: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. 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 puppet-dev+unsubscr...@googlegroups.com > > (mailto:puppet-dev+unsubscr...@googlegroups.com). > > To post to this group, send email to puppet-dev@googlegroups.com > > (mailto: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 > (mailto:puppet-dev+unsubscr...@googlegroups.com). > To post to this group, send email to puppet-dev@googlegroups.com > (mailto: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.
