This patch is legendary. +1

Rein Henrichs
http://reductivelabs.com


On Sun, Mar 14, 2010 at 8:05 AM, Markus Roberts <[email protected]>wrote:

>
>
> 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]<puppet-dev%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>

-- 
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.

Reply via email to