On Nov 4, 2008, at 3:42 PM, Florian Grandel wrote: > > Hi Luke, > >> In other words, I think the low-cost approach (fixing current stuff) >> is not the right idea here, and a higher-cost approach (where cost is >> mostly design) is the right solution. > > That's ok for me. > >> This would obviously be straightforward, at this point, in that one >> could just use the existing definition syntax for adding parameters, >> although it would further confuse the distinction between them. > > That's not a problem for me as I don't see a profound difference > anyway. ;-) > >> I'm amenable to this change as a short-term mechanism for adding >> attributes to classes, but I would tend to require a change with it: >> The '$class::attribute' syntax would only be able to see the >> attributes mentioned in the prototype, rather than any internal >> variables. > > What do you mean by prototype? The class definition? (As opposed to a > class instance?) I am used to the distinction "prototype vs. > singleton", > that's why I might be confused by your use of the term "prototype" > here.
Sorry, I thought the term 'prototype' was often used for things like 'function prototype', as in, the thing that defines how the function is used. Yes, I meant, in your parlance, the class definition. > > If you mean the class definition by "prototype" then I didn't get your > point. I still see various possibilities to maintain other attributes > than those passed into a class as "parameters": > - You can use "$class::attribute" with constant values, even derived > or > somehow calculated values are ok as long as they are constant at > runtime. This means the value can be declared in the class definition > and is otherwise read-only. (My preferred solution) > - You can set the value of "$class::attribute" from "outside". I don't > know what this could be good for because I didn't have a use-case for > this yet. (So to keep it simple and clear I wouldn't do that...) > > In both cases you could maintain "independant" class attributes. If you allow external attributes for classes (that is, attributes set like those in definitions) you now have two sets of attributes: The external attributes, which are obviously publicly known, and internal variables, used for who-knows-what. What I'm saying is that I'd like to once again hide the latter set of attributes, if we get a different set of public attributes. This way the developer has some control over whether every little variable in a class is exposed. Either that, or add a keyword that specifies that a given variable is exposed publicly. > >>> If public class/definition attributes were missing, however, I >>> could well do without them. >> >> You'd retain all of this; you just wouldn't have it to *all* >> variables, just those that are mentioned in the prototype. > > I think we have a misunderstanding here. I didn't mean that public > class > attributes need to be taken away. I just wanted to say that if you > didn't introduce public attributes into /definitions/ then I > wouldn't mind. I know you didn't mean that, but I'd want that if we added other public attributes. -- He is indebted to his memory for his jests and to his imagination for his facts. --Richard Brinsley Sheridan --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
