On Feb 24, 2011, at 1:37 PM, Brice Figureau wrote:
> On 23/02/11 07:05, Luke Kanies wrote:
>> I thought this design point would be interesting, assuming I can make
>> it sufficiently clearly.
>>
>> I just did a refactor of my Interfaces work - previously, I had a
>> base class of Puppet::Interface, and all interfaces were subclasses
>> of that class.
>>
>> However, once Dan Bode asked for a separation between interfaces that
>> used the Indirector and those that didn't, I suddently had the base
>> class, a new Puppet::Interface::Indirector class, and then subclasses
>> of each. Then the code smell showed up.
>>
>> Basically, I had to mark the Indirector class as 'abstract', because
>> it's not actually an interface, it's just another base class. Then I
>> recognized the pattern that I've been trying to get away from - a
>> base class heirarchy, then an instance class heirarchy, with almost
>> no instance functionality in the whole chain.
>>
>> So, I converted the whole thing - Interface is still the base class,
>> and Indirector is still a subclass, but all interfaces are just
>> instances of one of those two (or any other subclass). It works
>> essentially identically, other than initialization:
>>
>> Puppet::Interface.new :plugin do action :download do .... end end
>>
>> But I'm also defining all of the appropriate constants, so adding
>> actions can be done the same way:
>>
>> Puppet::Interface::Plugin.action :foo { ... }
>
> So that means each interface instance is essentially a singleton, is
> that right?
Yes.
>> As to benefits, primarily it's about general code maintainability.
>> It was nearly impossible to determine if a given method was base
>> class functionality, subclass functionality, instance functionality,
>> or what. Here, it's all very clear and very simple.
>
> I guess I should read the code, beacuse it doesn't look clear and simple
> from here :)
What do you mean? Do you mean that it's hard to tell where functionality lives
in the existing code, or that my explanation does not make it clear?
>> There are a few other places that need this same refactor -- notably
>> Puppet::Type. Hopefully some day. :)
>
> So, when will this be merged in the core (and will it be)?
My current goal is for it to be in the next feature release, but I don't know
if that will happen. I'm still doing a lot of iteration on it right now.
> I'm currently polishing my puppet instrumentation patch, which would
> greatly benefit from using this interface layer for controlling the
> instrumentation plugins. But I don't think I can send here a puppet core
> patch that at the same time depends on external code (or could I?).
Hmm. That would be complicated. I think it would be reasonable to do so for
the next feature release, and then we can focus on getting the interface work
nailed down and merge it before release. I am just hesitant to merge it in now
because I want people who are using Puppet in production right now to be able
to try it, and with it in a separate repo, they can.
--
You don't learn anything the second time you're kicked by a mule.
-- Anonymous Texan
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
