Mailing List Archive: Zope: Dev

Move implementation of getParent to zope.location?

Index | Next | Previous | View Threaded

thomas at thomas-lotze

Aug 3, 2009, 11:49 PM

Post #1 of 8 (1132 views)
Permalink

Move implementation of getParent to zope.location?

There are two functions in zope.traversing.api, getParent and getParents,
that are rather closely related. The former is implemented right in that
module while the latter adapts its argument to
zope.location.interfaces.ILocationInfo and calls getParents() on that.

Why is getParent not a part of ILocationInfo? If there's no good reason,
I'd propose adding getParent() to the interface and changing the getParent
function in zope.traversing to work similarly to getParents, i.e. call a
method on an ILocationInfo adapter.

--
Thomas

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

faassen at startifact

Aug 6, 2009, 9:43 AM

Post #2 of 8 (1073 views)
Permalink

Re: Move implementation of getParent to zope.location? [In reply to]

Thomas Lotze wrote:
> There are two functions in zope.traversing.api, getParent and getParents,
> that are rather closely related. The former is implemented right in that
> module while the latter adapts its argument to
> zope.location.interfaces.ILocationInfo and calls getParents() on that.
>
> Why is getParent not a part of ILocationInfo? If there's no good reason,
> I'd propose adding getParent() to the interface and changing the getParent
> function in zope.traversing to work similarly to getParents, i.e. call a
> method on an ILocationInfo adapter.

One question to ask is whether getParent and getParents are used all
over the place or just by zope.traversing. If they're only used by
zope.traversing we might not want to move them to a more general place,
but perhaps we can even see about removing them.

But really, +1 to moving these functions to zope.location.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

thomas at thomas-lotze

Aug 12, 2009, 12:26 AM

Post #3 of 8 (1007 views)
Permalink

Re: Move implementation of getParent to zope.location? [In reply to]

Martijn Faassen wrote:

> One question to ask is whether getParent and getParents are used all over
> the place or just by zope.traversing. If they're only used by
> zope.traversing we might not want to move them to a more general place,
> but perhaps we can even see about removing them.

getParent is used by a number of zope.app.* packages (apidoc, container,
dependable, onlinehelp, preference, rotterdam, pythonpage, workflow). Its
only other occurrence is in zope.traversing where it is defined, but not
used.

getParents is used by zope.app.* packages as well (rotterdam, tree,
workflow) and definitions of it occur in zope.location and
zope.traversing, where it isn't used either, though.

Seeing this now, I agree to removing the functions provided nobody objects
against removing parts of the API that might be depended on by client code
out there. (Both functions are actually exported by zope.traversing.api.)

--
Thomas

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

jim at zope

Aug 12, 2009, 2:39 AM

Post #4 of 8 (1006 views)
Permalink

Re: Move implementation of getParent to zope.location? [In reply to]

On Wed, Aug 12, 2009 at 3:26 AM, Thomas Lotze<thomas [at] thomas-lotze> wrote:
...
> getParent is used by a number of zope.app.* packages (apidoc, container,
> dependable, onlinehelp, preference, rotterdam, pythonpage, workflow). Its
> only other occurrence is in zope.traversing where it is defined, but not
> used.
>
> getParents is used by zope.app.* packages as well (rotterdam, tree,
> workflow) and definitions of it occur in zope.location and
> zope.traversing, where it isn't used either, though.
>
> Seeing this now, I agree to removing the functions provided nobody objects
> against removing parts of the API that might be depended on by client code
> out there. (Both functions are actually exported by zope.traversing.api.)

I object to removing API functions that client code might use. (Was
that a trick questions?) What is the point of this exercise?

Jim

--
Jim Fulton
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

jim at zope

Aug 12, 2009, 3:06 AM

Post #5 of 8 (996 views)
Permalink

Re: Move implementation of getParent to zope.location? [In reply to]

On Wed, Aug 12, 2009 at 5:56 AM, Thomas Lotze<thomas [at] thomas-lotze> wrote:
> Jim Fulton <jim [at] zope> schrieb:
>
>> I object to removing API functions that client code might use. (Was
>> that a trick questions?) What is the point of this exercise?
>
> Sorry, this message shouldn't have been sent in the state it was.
>
> The original point of the exercise was to clean up the situation where
> the two closely related functions aren't part of the same APIs. Then I
> responded to the suggestion of removing the functions, noticing two
> things as I wrote: the functions are used by zope.app packages, and
> they are part of zope.traversing.api but not used by anything
> non-zope.app. As api-style modules have been questioned in the past, I
> wanted to raise the issue whether the functions are meant to remain
> part of that module or live in the ILocationInfo interface alone, but I
> got distracted at that point and for some reason sent the message,
> which I shouldn't have done.
>
> If the functions remain in the api module, the remaining issue would be
> whether to move the implementation of getParent to zope.location and
> thus treat it like getParents.

Right. I understood this in the original proposal. Given that it
doesn't break the existing API, I have no major problem with it, which
is why I didn't bother to respond in the first place. I have a small
problem that it fattens an existing API. I have a larger problem that
we are wasting time on this. The cleanup doesn't seem worth it to me.
I especially don't like that *I'm* spending time on this rather than,
say, working on the kgs or our buildout discussions.

Jim

--
Jim Fulton
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

faassen at startifact

Aug 25, 2009, 9:06 AM

Post #6 of 8 (873 views)
Permalink

Re: Move implementation of getParent to zope.location? [In reply to]

Thomas Lotze wrote:
> Martijn Faassen wrote:
>
>> One question to ask is whether getParent and getParents are used all over
>> the place or just by zope.traversing. If they're only used by
>> zope.traversing we might not want to move them to a more general place,
>> but perhaps we can even see about removing them.
>
> getParent is used by a number of zope.app.* packages (apidoc, container,
> dependable, onlinehelp, preference, rotterdam, pythonpage, workflow). Its
> only other occurrence is in zope.traversing where it is defined, but not
> used.
>
> getParents is used by zope.app.* packages as well (rotterdam, tree,
> workflow) and definitions of it occur in zope.location and
> zope.traversing, where it isn't used either, though.
>
> Seeing this now, I agree to removing the functions provided nobody objects
> against removing parts of the API that might be depended on by client code
> out there. (Both functions are actually exported by zope.traversing.api.)

I think that means we can't remove it. I'd say move it.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

ct at gocept

Sep 9, 2009, 5:48 AM

Post #7 of 8 (722 views)
Permalink

Re: Move implementation of getParent to zope.location? [In reply to]

Hi there,

On 08/12/2009 12:06 PM, Jim Fulton wrote:
>
> Right. I understood this in the original proposal. Given that it
> doesn't break the existing API, I have no major problem with it, which
> is why I didn't bother to respond in the first place. I have a small
> problem that it fattens an existing API.

As far as I understand, the method is there and used and should have
been in that existing API in the first place.

Also, as you say it's only a small problem for you, I guess Thomas can
go ahead moving it.

> I have a larger problem that
> we are wasting time on this. The cleanup doesn't seem worth it to me.
> I especially don't like that *I'm* spending time on this rather than,
> say, working on the kgs or our buildout discussions.

I see truth in what you say, but this answer also takes energy from
people who'd like to spend time on improving small things (which quickly
sum up to larger things) pushing them away from contributing. I don't
think we can afford that.

Christian

--
Christian Theune � ct [at] gocept
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 0 � fax +49 345 1229889 1
Zope and Plone consulting and development
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

ct at gocept

Sep 9, 2009, 5:48 AM

Post #8 of 8 (728 views)
Permalink

Re: Move implementation of getParent to zope.location? [In reply to]

Hi there,

On 08/12/2009 12:06 PM, Jim Fulton wrote:
>
> Right. I understood this in the original proposal. Given that it
> doesn't break the existing API, I have no major problem with it, which
> is why I didn't bother to respond in the first place. I have a small
> problem that it fattens an existing API.

As far as I understand, the method is there and used and should have
been in that existing API in the first place.

Also, as you say it's only a small problem for you, I guess Thomas can
go ahead moving it.

> I have a larger problem that
> we are wasting time on this. The cleanup doesn't seem worth it to me.
> I especially don't like that *I'm* spending time on this rather than,
> say, working on the kgs or our buildout discussions.

I see truth in what you say, but this answer also takes energy from
people who'd like to spend time on improving small things (which quickly
sum up to larger things) pushing them away from contributing. I don't
think we can afford that.

Christian

--
Christian Theune � ct [at] gocept
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 0 � fax +49 345 1229889 1
Zope and Plone consulting and development

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads