[Freeciv-Dev] Re: (PR#8632) Easy way to set map size with auto ratios (seteables if desired)

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >


For the same reason that map coordinates are the standard coordinate
passed as arguments (and thus need not be checked for realness),
all map dimensions should be passed as native which is the properly
defined storage subset used in savegames and comparable network
exchange of such.

Natural coordinates may have utility in the GUI as part of user
display enhancements, but not the core low-level functions like
map storage and exchange of stored map values.


Special values like (-1,-1) are well defined and necessary so not a
problem. The conversion of such values from network to internal form
should have no problem making -1 an appropriate value in whatever
wordsize is chosen if it should change. So this is not a problem
unless someone choses to ignore/forget the standard rules for this
and build bugs into such code.


Many of these "changes" that are breaking standard rules will have a
lot of maintenance and robustness consequences. There are a number I
have not had time to fully document and raise hoping that Marcelo
and other reviewers would have the sense to look at new code with a
critical eye. The reflex action to any significant change should be what
standards is it breaking, why is it doing it, and can the same effect
be had by coding it in a standards conforming way, or is it just not a
useful concept and therefore should be dropped.

The corollary to breaking established coding standards, that is adding
lots of oneoff types of constructs rather than a generic template with
optional parameters to get the specific oneoff constructs, and
corresponding consolidation of new code into generic and optional parts,
rather than confusingly complex and no longer shareable individual and
possibly optimized codepaths is another of the bad areas of the original
patch that needed to be rolled back to the original freeciv code forms.


It is unfortunately the case that new coders do not know the Freeciv code
standards or why they have arisen over time. This is no excuse for reviewers
not to educate people and conversely every reason for new coders to take this
opportunity to learn something from past Freeciv developers rather than get
into long discussions of whose new way to do something is better. When the
past code standards are being violated, the standard should by far have the
weight in the discussion with a high degree of strong arguments required to
make even the smallest changes, which then need to be well documented with
the argument summarized for future discussions of the sort.

The main rationale for standards is robustness in that you do not need to
check all the code for problems when adding new code that is standards
conformant. The second is that over time it makes coding much easier as
many things are just canned practices with new code being added to the
special case edges and not the whole core outwards.

The con is that new coders get bored and don't take the time to research
Freeciv beyond their initial bright idea and prototype, so there is a lot
of tension between people finishing the job properly. Maintainers also are
guilty of not explaining just what is needed and why, making a lot of
discussions more specialized (hence personal style) and less generic (there
are real technical reasons).

Cheers,
RossW
=====

Marcelo Burda wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> 
> Le jeu 03/06/2004 à 00:36, Jason Short a écrit :
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
>>
>>Marcelo Burda wrote:
>>
>>><URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
>>>
>>>Le mer 02/06/2004 à 22:49, Jason Short a écrit :
>>>
>>>
>>>><URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
>>>>
>>>>>Marcelo Burda wrote:
>>>>
>>>>>>LAST CHANGE
>>>>>>drop changes in aigoto and citytools
>>>>
>>>>Oh, and...
>>>>
>>>>Rather than creating a new network type XYSIZE, we should just change 
>>>>COORD to be a SInt16.  It should be signed so that eventually we can 
>>>>pass negative values as the "special" coordinates rather than 255,255 
>>>>like we do now.
>>>>
>>>>Don't worry about changing any of the other values in the network code. 
>>>> We can keep using 255,255 and keep MAX_LINEAR_SIZE as 254 for now.
>>
>>>hmmm, i no like it. are your sure this is a best way. XYSIZES and COORD
>>>are differents think. 
>>>and if we not correct the net code this will broken capability concept.
>>>today sending 255 as spetial value later 65535. i we change to big coods
>>>this need to be well done. but probaly we never will need this. we can
>>>make 30000 tiles maps with UINT8 for the map coordinates.
>>
>>XYSIZES is a native dimension whereas all COORD values are map coordinates.
>>
>>However COORD should be able to cover native and natural coordinates as 
>>well.  There's no telling what we'll want to use in the future.
>>
>>No, I'm not sure it's the best way.  But I don't really see any 
>>drawbacks to it.  If we define COORD as any tile coordinates then 
>>XYSIZES is a type of COORD.
> 
> but we only send map coordinates to clients. natural or native ones are
> only used for calculation usage. why you want define COORD as all
> cordinates system. and not only the map one. that is not so clean as
> definition to coders.
> 
> for me the "problem" are than:
> -COORD need to be well defined as a single coordinate system.
> 
> -one change  XYSIZES need 2byte per game more to be send
> change COORD need, a grat big more number of bytes per game (no so
> important)
> 
> -we need obsolutly coorrect the 255,255 spetial value now, forcint to
> tooch so much code.
> 
> -the change is (for me) unneeded
> 
> -i begin borning with this patch ;-)
> 
>>jason
>>
>>
> 
> 
> 
> 
> 
>