On Fri, 2008-12-19 at 21:22 -0800, Edward Hennessy wrote:
> On Dec 18, 2008, at 7:16 AM, Peter Clifton wrote:
> >
> > Each file we compile takes a certain overhead of time. For
> > collecting a
> > few simple routines such as m_*_shortest_distance(), I'd prefer to see
> > one new file, m_gemetry.c rather than several small files. Having lots
> > of very small files also makes navigating and editing the source
> > harder
> > in some cases.
>
> I can see m_box.c and m_circle.c gaining functions over time. If so,
> keeping them in separate files increases each module's cohesion.
> Keeping the function name's prefix the same as the base filename seems
> to follow a convention in the code. Also, having the function name's
> prefix associated with the first parameter ("this") also seems to
> follow a convention in the code. These two conventions have made
> navigating the code relatively easy for me.
Ok, I'll put those back. (I was just about to push some changes out).
Join me on #geda at irc.seul.org?
> I don't mind which way this goes, but so far, the changes I've been
> asked to make to my patches are inconsistent. I've been asked to use
> glib numeric constants instead of C constants, then use C fundamental
> types instead if glib types.
I'm going to duck out of any debate here. As you point out, that is a
bit contradictory. I don't know why we're avoiding C constants, nor for
that matter why glib defines gdouble etc..
> Is eliminating libgeda's dependency on glib really a requirement?
No, that was probably a dumb reason to choose. However, conventions I
see in other such libraries is to avoid exposing types which are
dependant on the platform. GLib is a fairly decent portability layer
which we use a lot in libgeda, so no - it won't be going away any time
soon.
> > What about altering the prototype of the o_shortest_distance()
> > routine:
> >
> > +double shortest_distance (OBJECT *object, int x, int y, int
> > override_solid)
>
> This would eliminate the other switch statement. A definite
> improvement.
Cool, I've implemented that.
> Also, I would create a wrapper function so the override_solid
> parameter is not exposed in the public interface. The parameter
> causes specialized behavior required internally by libgeda, so hiding
> it from the public interface seems appropriate.
Could do, but I wouldn't bother.
> (Off the subject: I've created switch statements where cases were in
> numerical order with no gaps, and the GNU compiler optimized it to a
> jump table. I was amazed. I've never seen that with any other
> compiler.)
That's pretty keen of it! Does that behaviour depend on the ordering of
case statements?
> The functions in m_box.c and m_circle.c are more generic. The
> proposed function prototype in o_basic.c would be specialized for
> object selection. If libgeda gets used for more applications in the
> future, it is probably better to keep the functions on the generic side.
Ok, I'll put them back before I push.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
