gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: cached rev support in pyarch


From: David Allouche
Subject: Re: [Gnu-arch-users] Re: cached rev support in pyarch
Date: Sat, 12 Jun 2004 15:18:35 +0200
User-agent: Mutt/1.5.5.1+cvs20040105i

On Fri, Jun 11, 2004 at 11:28:07AM -0400, Aaron Bentley wrote:
> David Allouche wrote:
> >What annoys me most at the moment is functionality duplication, like
> >Category.iter_branches and Category.get_branches. The typical change I'm
> >considering is:
> >
> >  - removing the Category.branches property
> >
> >  - removing the Category.get_branch method
> >
> >  - renaming Category.iter_branches to Category.branches
> >    (making it a method instead of a property)
> >
> >Of course, since that would probably break a lot of code, that would
> >go only in the next version.
> 
> If I wanted to achieve that, I'd probably take these steps:
> 1. add iter_branches, deprecate branches
> 2. remove branches
> 3. add branches as an alternate name for iter_branches, deprecate 
> iter_branches
> 4. remove iter_branches
> 
> It takes a while, but if you have enough client code, it's probably good 
> to avoid breaking stuff.

I'm sure not going to go that way! PyArch is still alpha stuff. That
deprecation scheme is appropriate for stable, released, post 1.0 code,
but part of the point with alpha code (i.e. pre-0.9) is to be able to
break things pretty hard. Well... maybe I should have used 0.1 as a
version id...

> Alternative: add a new namespace where iterators are the standard approach.

That sounded seductive at first, but on second thought, I do not think
it would help much. If I understand well, the point of the separate
namespace is to provide a smooth transition path, like:

  1. iarch standard implementation, only iterators
     arch  compatibility module, sequences too
           deprecation warning on import

  2. arch  standard implementation, only iterators
     sarch compatibility module, deprecated

  3. remove sarch

But again, I think that's too much trouble for alpha releases...

Here is my proposal: make a "incompat" branch for backwards incompatible
changes and cleanups before 0.6, where changes will be discussed hands
on, then merge the agreed upon changes in when making the 0.6 release.

-- 
                                                            -- ddaa




reply via email to

[Prev in Thread] Current Thread [Next in Thread]