[r-t] Practical Extension

[John Harrison]

Sorry to come late into this thread.  It began while I was away and the
longer I put off digging in the more indigestible it looked.

In article
<CAK5=Z=n-cjZLYaB+RvhqGojnAqCW4OfApuU8u5rA7=UnvjsJPA at mail.gmail.com>,
   Pip Dillistone <tuftyfrog at gmail.com> wrote:
> ... hoped that the new guidelines ... would ... recognising that an
> obsession with laying down axiomatic rules of extention had failed and
> got us in the present predicament. I'd also hoped that they would put a
> mindset of "permissiveness" front and center ...

Overall, this has been the approach, as Tim said in his reply.  But
extension is a more difficult problem to resolve than some of the other
areas:

The requirement to respect historical continuity means it is essential to
understand exactly what the current rules mean, and to try to describe them
in a more accessible way (to meet the requirement for simplicity).  That is
no mean feat.  

The requirement for permissiveness means admitting (and possibly
describing) other extension mechanisms.  That would not be too difficult,
but it raises a more fundamental and difficult problem.

Extension is a mechanism for preemptively taking over portions of the
method namespace. With tightly prescribed extension mechanisms there is a
well defined process for predicting what the effects will be, but the
acceptance of new, possibly not yet described, extension mechanisms there
will be many overlaps and conflicts that can't be predicted, and could be
discovered retrospectively.  

That raises two further questions.  The first is whether any reasonable
bounds can be set on what consitutes an extension, is it possible to bound
the process of relating methods at different stages in any reasonable way? 
'Reasonable' is of course subjective so requires some sort of consensus.

The second question is how to best to manage the conflicting name claims
that derive from multiple extension mechanisms.  

In answering the above questions it seems sensible to review the various
preservation rules that are currently imposed on extensions.  Should they
all be retained (as part of the essence of an extension)?  Should they be
ranked in order (as part of the process for managing conflicts?

All of this makes extension much harder to do properly (permissive, simple,
respect history, etc) so quite likely it won't all be done in one go if the
initial version of the framework comes out in a sensible timescale.

> if it's really that difficult to codify permissiveness (an oxymoron if
> ever I heard one) then the whole thing should just be got rid of.

It's not the permissiveness that needs codifying - that's easy, people can
ring what they want.  The codification is for how we describe things, and
that is obviously harder with a permissive approach because you need to be
able to describe more things unambiguously.

'Getting rid of extension' would not be sensible.  Quoting from 'Decisions
Decisions' **

--------------
Do we need rules on extension?
Given that ringers like the idea of sharing names between methods that seem
related at different stages, and given that trying to work out how to do it
can be quite complicated, there is a clear need for something to help do
it, and it would certainly not be sensible to throw away all the work that
has gone into trying to make sense of extensions and the relationships
behind them.  So better questions would be about:

* How the knowledge on extensions can be most effective
* Whether the relationships described in the Decisions are the only valid
ones that should be used
* Whether extensions should always be subject to every one of the
constraints listed. 

It has been suggested that instead of the information about extensions
being presented as rules to be obeyed, it could be presented as guidance to
help people seeking satisfactory extensions to find them.  This would
recognise the fact that people may wish to use extension relationships
other than the ones already described, and that in individual cases people
may wish to make some compromises to get a workable extension.  

If someone developed a new type of extension that looked like being more
widely applicable, then it would be sensible to add it to the guidance so
that others can benefit from the accumulated wisdom of those who have
already used it.
--------------
** Still available at:  http://jaharrison.me.uk/New/Articles/Decisions/

-- 
John Harrison
Website http://jaharrison.me.uk