Re: [glob2-devel] About maps backward compatibility

[Bradley Arsenault]

On 4/16/07, Cyrille Dunant <address@hidden> wrote:
> Maps are long to make.

True, this is one barrior keeping me.

> Good maps are rare, and we already have few. It is completely silly to
> eliminate backward compatibility for the sake of it.

The good maps can be remade fairly easily. Its the idea, theme, and
relative sizes of the maps that count.

> It destroys hours of work of many people that did the maps.
>
> It forces us to get a new set of maps
>
> It serves no purpose as basically you can perfectly have a new and old map
> format: you only need a filter.

Not really true. The new structure has data where the original didn't
and vice versa. It requires completely loading the old structure,
which means retaining all of the old code, and converting it to the
new structure. This is not only dirty, but its gonna be a hell hole of
bugs.

> It introduces new bugs where there weren't (make no mistake, all code is
> buggy, and there is no reason a rewrite will be less buggy than the original)

Not true!

There are ways to design code that make it non buggy. And I have
introduced this and argued this. Glob2 lacks code foundation. It
doesn't have small functions that are garunteed to work. Algorithms
are long, and hacks and fixes are injected everywhere. The Map code is
the only exception, where most of the functions are simple and based
upon an "idea". The documented and easily understood idea gives
stablility when working with the Map class, I very rarely see bugs in
Map code.

The lack of documented behaviour, and the injection of hacks and
bugfixes everywhere else makes Glob 2's code much more buggy, as bugs
are easily introduced when semantics aren't understood.

> So unless there is a compelling reason to redo any subsystem at all (this is
> especially true for the maps), I think it is a bad idea in general: if it
> ain't broke, don't fix it!

Its not that things are broke. Its like using a *really* old car. The
old car works. But it sucks gas, the engine is loud, the oil has to be
changed frequently, the brakes have slow responce time. And the
mechanics can't understand how the damn thing works. It works. But not
very well, and its not easy to change.

> Now there _are_ problems, for instance, network play needs to be flawless, and
> if that takes a rewrite, so be it! But it serves absolutely no purpose
> whatsoever to break backward compatibility for no purposes other than to
> essentially destroy valuable work.

That is completely untrue. We are not breaking backwards compatibility
on purpose. Backwards compatibility is merely a by-product of changing
the internal structure of Glob2 to be more maintainable, flexible, and
less buggy.

> Because make no mistake: having good maps (or having maps at all) is _way_
> more important than saving five minutes by not implementing a filter.

Your not the one working on this so I suppose I can't expect you to
understand the difficulty. Implementing a filter would defeat the
purpose of the system in the first place because it would require all
old code to remain in place, and new code built on top of it, which
would make a mess of the code.


>  -- CFD
>
> PS, in general, rewriting for the sake of it is not a good idea, unless you
> found some basic architectural flaw.

And there are basic architectural flaws. Glob2's map header system has
badly defined semantics, and the placing of variables is often
difficult and requires hacking in to get it to work.

> PPS and from a development perspective, rewrites of subsystem should be done
> in separate branches and merged when well-tested and feature-complete.

Also Glob2 is technically in Alpha, and somewhere in our website the
definition of Alpha means that things may change rapildy and backwards
compatibility is not garunteed.


--
Really. I'm not lieing. Bradley Arsenault.