Not caught up on this thread yet, but I just want to offer a heads up
that I think I've got a very simple change to mitigate much of the
duplication. 

More later,
Ross

Rob Miller <robm@...> writes:

> Wichert Akkerman wrote:
>> On 6/29/09 9:27 PM, Rob Miller wrote:
>>> Wichert Akkerman wrote:
>>>> I think our opinions are pretty firmly rooted and not likely to
>>>> change. I'ld like to hear some other opinions on this as well!
>>>
>
>>> i agree w/ you, wichert; i'm not super fond of forcing the developers to
>>> use yet more marker interfaces in order to keep using membrane. but i'm
>>> finding some amusing irony in this conversation, b/c the idea of using
>>> the I*able marker interfaces was originally MY idea, and it was actually
>>> ross who talked me out of it.
>>
>> So when the to of you swapped maintainer and developer roles you
>> swapped opinion as well? :)
>
> yup.  we're switching cars later this month, and are working on the
> paperwork to trade houses.  another year or so and we should have
> completed the transition.
>
>>> anyway, in that conversation, ross made a suggestion that i thought was
>>> quite clever, which removed the bloat from the index and just generally
>>> made everything much simpler, so much so that my objection to the index
>>> evaporated. it's similar in spirit to what you're proposing, wichert,
>>> but different in details. hopefully ross won't mind that i include
>>> it here:
>>>
>>> <ROSS>
>>> A quick audit of membrane and remember indicates that the following
>>> interfaces are being queried on: IMembraneUserAuth, IUserAuthProvider,
>>> IMembraneUserGroups, IGroup, IMembraneUserRoles, IMembraneUserChanger,
>>> IMembraneUserDeleter, IMembraneUserProperties, and IReferenceable. Are
>>> all of these queries likely to be valid and necessary?
>>>
>>> Whatever interfaces we do need to query on, maybe we can use
>>> zope.component.interface.provideInterface to register all those
>>> interfaces as utilities providing IMembraneQueryableInterface:
>>>
>>> zope.component.interface.provideInterface(
>>> '', IMembraneUserAuth, IMembraneQueryableInterface)
>>> zope.component.interface.provideInterface(
>>> '', IGroup, IMembraneQueryableInterface)
>>>
>>> alternatively, if ZCML doesn't make you puke:
>>>
>>> <interface
>>> interface="Products.membrane.interfaces.IMembraneUserAuth"
>>> type="Products.membrane.interfaces.IMembraneQueryableInterface" />
>>> <interface
>>> interface="Products.membrane.interfaces.IGroup"
>>> type="Products.membrane.interfaces.IMembraneQueryableInterface" />
>>>
>>> Then we can convert the object_implements index to a more focused one:
>>>
>>> def object_implements(object, portal, **kw):
>>> return tuple(
>>> iface.__identifier__ for iface in
>>> component.getUtilitiesFor(
>>> IMembraneQueryableInterface, context=portal)
>>> if iface.providedBy(object))
>>
>> That assumes the object provides that interface directly.
>
> ah, right, i noticed that originally as well, and commented on it in
> the original thread from which i pulled that quote.
>
>> How easily can that be changed to handle adaptibility as well?
>
> this is all untested, but that seems at first glance a trivial change:
>
> def object_implements(object, portal, **kw):
>    return tuple(
>       iface.__identifier__ for iface in
>       component.getUtilitiesFor(IMembraneQueryableInterface, context=portal)
>       if iface(obj, None) is not None)
>
>> This is ZCA magic I haven't encountered before so I'm not sure how
>> exactly that would work.
>
> conceptually this is almost exactly what you suggested.  the only
> thing that's different is that you hardcoded a set of "features", by
> mapping feature names to interfaces, where ross uses the ZCA to "mark"
> certain interfaces rather than hardcoding.
>
>> It's a bit more magic than my proposal, but I do like the easy
>> extensibility.
>
> i don't think there's a lot of magic here, really.  it seems to me a
> typical to-ZCA-or-not-to-ZCA choice; one is more clear, b/c the set of
> pertinent membrane interfaces is written out in code right in front of
> you.  the other is more extensible, b/c you can register any interface
> as a membrane interface in the config.
>
>> I definitely prefer this above the current I*Avail approach. I
>> suppose that means that Ross should have been more stubborn :)
>
> indeed.  or i should've.  hard to tell at this point... ;)
>
> -r
>
>
> --
> Archive: http://www.coactivate.org/projects/remember/lists/remember/archive/2009/06/1246317275211To unsubscribe send an email with subject "unsubscribe" to remember@....  Please contact remember-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+b@... for questions.