Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: Map coordinate cleanups.
Home

[Freeciv-Dev] Re: Map coordinate cleanups.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Map coordinate cleanups.
From: Jason Dorje Short <jshort@xxxxxxxxxxxxx>
Date: Thu, 16 Aug 2001 22:13:58 -0400

Gaute B Strokkenes wrote:
> 
> On Thu, 16 Aug 2001, jshort@xxxxxxxxxxxxx wrote:
> >
> > Are you saying there is a reason other than speed to make them
> > macros?
> 
> Yes.  For one thing, this makes it feasible to put them in other
> places where it would be silly to use a function.  A slightly cheesy
> example would be the definition of IS_PROP_TILE(), which basically
> IS_NORM_TILE && IS_REAL_TILE.  That would be a silly thing to write in
> terms of functions.  A somewhat more relevant example might be the
> adjc_dir_iterate() macro you wrote.  I added an assert() which
> amounted to IS_PROP_TILE() to it before committing it.  This actually
> had a measurable impact on performance, and having a function call
> would probably make it even slower.  Doing it this way means that we
> can use the macro there with no worries.

Um, all of those reasons are just "it is faster".  I'm not disputing
that it's faster - I just don't really care.  Despite the
adjc_dir_iterate macro patch I made, I really don't care about speed
(especially when it's something a compiler *should* be able to optimize
anyway).  I believe the macro form is uglier, and I don't look forward
to having to replace it later to allow for orthogonal maps.  All of
these are small issues, though, and I don't think we should argue over
the macro/function thing any more.

> It seemed obvious to me that the phrase "normalize_map_pos" had been
> picked because of the meaning of normal or normalized as "in the
> preferred form" rather than the commonplace meaning as "plain,
> ordinary" which is how you seem to be interpreting it.
> 
> I then picked "proper" because that is the word which is most often
> used to exclude objects which fit the definition, but are not `nice'.
> For instance given a set A, A is a subset of A--but it is not a proper
> subset.

These definitions of normal/proper work just as well with my function
names.

normal = the preferred form = anything that's on the world and wrapped

proper = the nice form = anything that's wrapped

I see this as a bigger issue than the macro one; these names will be
around for a long time.  It would be nice to keep the current mindset
(normal=wrapped and real), but picking names that will make sense to
future programmers is even more important.

The problem is that normal and proper are, even in math, very similar
terms - and especially likely to confuse the average programmer.  What
other term could be used instead?  How about just is_wrapped_tile?

jason


[Prev in Thread] Current Thread [Next in Thread]