[m-dev.] shims

[Paul Bone]

On Tue, Sep 16, 2014 at 11:19:19AM +1000, Mark Brown wrote:
> On Tue, Sep 16, 2014 at 10:43 AM, Paul Bone <paul at bone.id.au> wrote:
> > Eww.  Well I understand that this would be possible in this way but if I
> > actually expect people to use it I think a nicer syntax would be best.
> >
> > Such as making it an (optional) part of module declrations.
> >
> > :- module my_module (2.3.1).
> 
> I also suggested 'feature' items, which might look nicer.
> 

I saw that and thought it very similar to detecting predicates based on
name, arity, and type/mode/detism.  But it's not as behaviour might change.

> Versions are not always ordered linearly. You can get a version with
> patch A, a version with patch B, then a version with both patches.

True.

Each proposal has benifits and drawbacks compared to every other proposal.
It may be good to implement multiple proposals.  This does make things
complex, however I think that by making things like versions easy to
express you reduce complexity.  

> >> (You keep the earlier minor versions since these represent backwards
> >> compatible changes, but you remove the earlier major version.)
> 
> ... and in so doing, you indicate directly what changes are backwards
> compatible without relying on any conventions regarding numbering
> schemes.
> 

Yep.  I beleive that the semantic versioning numbering scheme is less
complex than a series of numbered feature items.  But that feature items can
be used (in addition to version numbers) for non-linear changes.  For
example if you're developing a library and I fork it to work on a new
feature but my feature is not yet merged into your upstream library.



-- 
Paul Bone