Subject: [ggl] implementation constructs and their names
From: Bruno Lalande (bruno.lalande)
Date: 2009-06-03 05:17:08
> So we have (e.g. area)
> 1) the function area
> 2) the dispatch structure area with specializations, having method
> 3) several implementation struct's having method "calculate", dispatches are
> derived from them (in case of area some are derived the structs, some still
> call the functions)
> and for multi:
> 4) the dispatch structure area specialized for multi-polygon, derived from:
> 5) the more generic structure "multi_sum" with a policy, where the
> implementation struct of 3) perfectly serves as its policy
This scheme sounds clear to me. Structs should indeed be used
everywhere for the sake of consistency and genericity.
> However (HERE the question is): I'm doubting about the name. I like
> boost::mpl which has naming conventions: "type", "value", "type::value" and
"apply" is precisely the term I was thinking about while reading your mail...
> - "run" (as in arithmetic.hpp) as a method which can do something but also
> calculate something and return the result. The name "run" does suggest that
> something is happening. But for e.g. "num_points", calculating the number of
> points, it does not sound too logical to me
"run" sounds good to me for any kind of purpose, even calculating a
number (we run the calculation...).
> - "calculate" is appropriate for calculations, but often nothing is
> calculated -> then something is done (like removing holes). OTOH it is
> appropriate for e.g. intersections (which are "calculated' or "determined")
I would clearly discard this one, for the reason you give: only
adapted to the cases where something is actually computed.
> - "apply" (also here) can be used for anything but also here, like "run", is
> apply appropriate for returning the area-sum?
Like "run" this one sounds good to me, even when it comes to calculate
something. It has my preference above "run" because it reminds things
from Boost.MPL, Boost.Fusion and other, thus making the whole stuff
I think "apply" should be heard like "we apply the area function on
this geometry" or "we apply the intersection function on those
geometries" rather than "we apply the area of this geometry" or "we
apply the intersection of those geometries" which would sound
conceptually wrong. Once stated like that, "apply" goes everywhere.
> So we can take one or we can take several, based on circumstances, and then
> - "calculate" for everything returning an arithmetic value
> - "modify" for everything doing something on geometries
> - "determine" for everying returning a boolean
> However, this also has disadvantages, there will be unclear and/or
> additional cases (what about "parse").
Yep, that's the reason why I'd personally stick to only one term, the
one that seems to sound weird in as less cases as possible. "apply"
sounds best to me but I guess it's also a matter of taste...
> So I'm still doubting but think we should have one thing. What is then the
> most appropriate?
Having one unique term will improve consistency and readibility, which
IMO is more important than closely reflect what we're actually doing
at each line of code.
So to summarize I'd say: "apply" everywhere :-)
Geometry list run by mateusz at loskot.net