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.
