[Aptitude-devel] Improvement/simplification of the implementation of parsing sorting policies…

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Mon Feb 27 10:19:46 UTC 2012


2012/2/27 Daniel Hartwig <mandyke at gmail.com>:
> Even though no existing sorting policies made use of arguments and
> removing them has made it easier for you to make use of tokenizer, it
> is worth keeping the feature:
>
>  - the user manual states sorting policies share the same syntax
>    as grouping policies, which permit and use arguments;
>  - it is not causing any problems at the moment;
>  - future sorting policies may make use of it: consider a by-arch
>    policy which permits the user to specify some important arch(s)
>    to sort before others;
>  - if this is added back in the future (very likely), then the
>    translations of messages ("By-foo sorting polices takes no
>    arguments.") will have been lost in the meantime, generating
>    extra work for translaters.
>
> Had the original parser been problematic, I'd say this was a good
> choice (remove the problems and some disused features).  But since
> it was not problematic it is prefered to leave the code as it is,
> with the potentially useful features in place.
>
> Lastly, the ideal, final outcome outcome of any refactoring of the
> sorting or grouping policy parsers is to unite these two pieces of
> code since the format is identical between them.  There is this
> comment by D. Burrows to back up this statement:
>
> -- load_sortpolicy.cc
> //  Loads sorting policies -- similar to grouping policies.  (in fact, I did
> // this with cut&paste, and think maybe I should consider trying to share
> // code between the two parsers..)

I disagree.  So the way to produce the original code is fundamentally
the wrong way to do it, acknowledged by the original author.  However
this wasn't fixed for 6 years.  The whole file was unchanged since
those days, no new policy was introduced whatsoever in the ~6 years.

> D. Burrows has been working on making improvements to this code,
> including making it more generic.  This was being developed in
> load_grouppolicy.cc ("git log src/load_grouppolicy.cc").  That code is
> a fair bit more complicated, but any attempt to bring these two
> parsers together should definitely start from there instead of
> load_sortpolicy.cc.

My change, stripping the sorting policies and leaving a trivial amount
of mostly empty classes and trivial parser, actually paves the way for
refactoring the whole bunch of files to use a common method, seeing
that the conversion to anything else is equally trivial.

But I guess that you disagree, so sorry for that.

> For these reasons alone I seriously think it is worth reverting this
> change completely.

OK, go ahead then.

> If you have not done so already, I would strongly suggest becoming
> familiar with all of those files before continuing to develop major
> changes in aptitude.

OK, I will refrain from develop major changes in aptitude then.

Cheers.



More information about the Aptitude-devel mailing list