On Sat, Mar 13, 2010 at 11:56 PM, Luke Kanies <[email protected]>wrote:
> I like the idea, but does it make more sense to create a new > ScopeCollection class or something to manage this? > > All of this actually used to be in the Scope class, and I found it > confusing and difficult to manage there -- e.g., all of the Scope instances > have the methods for managing this data, but only the top scope actually > uses them. It makes reading the Scope class really annoying. > > Alternatively, maybe have a module that adds all of this behaviour, and > then only include that module in the top scope? My main motivation for this particular change at this particular time was that the combination of changes we already have in the queue should in theory make all this much simpler but was in fact making it all heinously complicated because data was tunneling through various structures whose only roll in that regard was to be there for the data to tunnel through--very much as if you took your end of the string out of the cage one way, I took mine out another, and rather than removing the string from the cage the result was to get it tangled in the bars. Continuing that physical analogy, the goal of this change is roll up part of the string into a ball, so that that piece at least winds up all going by the same route as I resolve the merge conflicts it creates. At that point, if the Scope class is too cluttered, then it might make sense to break it apart. Another side point, placing class scopes on (and only on) the top scope--or the compiler, which then becomes an outer-scope--is in effect a design decisions that could at least in principle have been made the other way; they could have been scoped/name-spaced the way everything else is, simplifying the code but altering the semantics. In this regard they are very like the ephemerals, in that both are classes of name-value bindings that follow slightly different rules than the normal. -- Markus -- 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.
