Re: [PATCH 1/1] Factor out a common pattern into a procedure.

[Ian Denhardt]

Quoting John Darrington (2014-10-19 03:40:36)
> It seems likely to me, that sometime we'll need the number of fields to be 
> parameterised,
> instead of hard coded at 2  (for example lynx has a directory component with 
> 3 fields in its URL)
> 
> Also I don't understand the significnace of the name version-take-api What 
> does API have to
> do with anything?

I started off with it as a parameter, then noticed the fact that it
was always the first two parts, so got rid of it. The thing is, this
*isn't* a coincidence. It's *very* common to have the first two parts
of the version encode compatibility information - when the second
number (minor) changes, the API has changed, but not in a way that
will break existing changes (though new programs may not work with
older versions). When the first number (major) changes, The API has
changed in a way that may break old programs. It's also very common
to have a looser version of this -- major indicates Big Changes, minor
is a feature release, and anything smaller than that is just bug fixes.

I'd be okay with adding the number of fields as an optional argument,
but I think given its typical use it should stay optional. I'd also like
the name to continue to reflect the semantics above; that seems to be
the common case. 

> Possibly an optional argument specifying the separator might be useful too.

I'm with Ludo and Mark on this one -- I think it's overkill.

How about this: separate it out into to functions: version-prefix, which
is the same as what I have now, but takes a (mandatory) argument
specifying the number of fields, and feature-version, which is defined
like:

    (define (feature-version version) (version-prefix version 2))

..with an appropriate docstring explaining the use case. Thoughts?

Also: as Mark requested, I will reorder the functions to keep
version-compare and version>? together.

signature.asc
Description: signature