So, it sounds like we're getting everything we wanted! That's great to hear.
So, I suppose that I should have been clearer. We are starting to label all variables and class calls with $::name to ensure that the full removal of dynamic scoping works properly. While more verbose, I find it to be much more clear and easier to maintain overall. What I'm actually doing is to use class variables in my providers so that I can bundle up all of my resource applications until the last one has passed through the catalog. This explains it with working examples https://www.onyxpoint.com/storing-puppet-provider-metadata-for-single-instance-application/ . It appears to be one of the more popular (of the limited) posts on my site right now and others that I've spoken with have expressed interest in doing this type of thing so anything that makes it easier/cleaner would be most welcome. Thanks, Trevor On Thu, Mar 13, 2014 at 10:16 PM, Henrik Lindberg < henrik.lindb...@cloudsmith.com> wrote: > On 2014-14-03 1:59, Trevor Vaughan wrote: > >> Henrik, >> >> All of this looks great to me. However, I was asked by someone recently >> if the language had the concept of a private class scope. >> >> Not yet. > > > We're seeing more patterns in the wild where people are creating classes >> that are only meant to be used internally to the class and not exposed >> to the rest of the world. >> >> The idea is to allow classes and defines in 4x to be private to a > module. That is, while they are visible in certain ways, it will not be > possible to instantiate them (i.e. create/include them in the catalog) from > outside of the module. (There may be other aspects of private that we may > want to add such as also not being able to read parameters of > such instances once they are placed in the catalog). > > Further, the idea is to also support private variables in classes - this > means that these variables can only be read from within the same class. We > may also add protected variables (only visible inside the class and a class > that inherits from it) - subject to debate and design, we are trying to > keep it as simple as possible... > > > Is there some way that the new scoping system could account for private >> classes? >> >> Yes, that is the idea. (Technically being "private" also has an effect > on other parts of the system; modules, loaders). > > > The best we could come up with right now is the idea of having a >> 'private' directory just to make it clear that they are not meant for >> public consumption but a 'private' keyword would be great so that the >> language itself could enforce the restriction. >> >> There will be a private keyword that can be used for classes, user > defined types, and functions as well as for class variables (other > variables are by definition already private). > > Likewise, we may also add the notion of private for resource types (i.e. > plugins in Ruby) and their attributes. > > We have some design work left to do on that (after all an agent needs to > be able to operate on them... > > Meanwhile, I think you can check calling module in your logic and call > fail if it is not from the same module. Not sure how well that works though. > > > Thanks, and looking forward to the performance gains (but a bit worried >> about my custom types that use cross-resource variables). >> >> The idea is that qualified names (anything with :: in them) are always > "external references", and they can only see what is visible to general > code. Intersted to hear more about our "cross-resource variables" and how > you think that may break - do you rely on relative name resolution? (if so, > prepare by always using global references that start with :: when you are > referring to something that is neither in the local scope, nor inherited) > > Regards > - henrik > > > > -- > 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 view this discussion on the web visit https://groups.google.com/d/ > msgid/puppet-dev/lftopi%24h9m%241%40ger.gmane.org. > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVcx-22ftvvjvZziS8s0PaZ3eEgD%3DjqLjqDtmXVyyeSqw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
