[Marble-devel] Projection classes

[Torsten Rahn]

On Thursday 01 May 2008 10:49:54 Inge Wallin wrote:
>
> switch (projection) {
>   case Sperical:
>      xxx1
>   case Rectangular:
>      xxx2
>   case Mercator:
>      xxx3
> }

Understandable.

> this is VectorMap::paintBase() which paints the background of the map
> before the actual map itself is painted. There are many more spread around
> the code.
> So, where should I put code like that? 

Well, I can't answer the question "like" that as I suspect that each of those 
cases is rather unique and hence would require a case by case decision.

For this particular case we are talking about backend code that is meant to 
perform an action that is specific to the plugin (the vector backend plugin). 
This action would have to be executed differently depending on the 
projection.

So we are talking about plugin specific code. Given that this plugin might be 
removed, replaced and accompaigned by other plugins I don't think that this 
code (which is very specific to this particular plugin and certainly won't be 
used elsewhere) should get added to our current projection class -- 
especially given that we'd like to maintain API/ABI compatibility somewhere 
this year. 
Another reason is of course the fact that "painting a backend" is not subject 
to a "projection" class. Have you ever seen a projection "paint a base"? No. 
A projection gets maybe used to paint something but the projection per se 
isn't responsible for tasks like this. 

So I don't think that this code should be added to the current projection 
classes.

Solution 2 would be about having a "dumping place" like set of projection 
helper classes where we collect code from different plugins that are specific 
to these classes and that don't fit elsewhere. A 3rd party developer of a 
plugin wouldn't be able to add further code to these helper classes without 
changing the original code or without shipping a set of helper classes 
inherited from the original helper class.

By the way: like with the other example you came up with this particular issue 
has a general solution for most "flat" projections ("draw a rectangle") and a 
special one for others.

> Right now I lean towards #1, but can be persuaded to use #2 or even some
> other, even better, scheme if somebody comes up with good arguments for
> either.

Yeah, this is definetly a "pick your poison case" (again I'm only talking 
about this particular paintBase case). 
For the reasons given I'd rather prefer #2 if I had to choose between those 
two. I dislike both solutions as they

a) encourage thoughtless additions of code that could actually get added in 
better ways and in a more generic way elsewhere. 
b) they don't take the nature of the plugin architecture into account.
c) they offer little merit over the existing switch statements (which I 
dislike, too) and add a significant amount of additional code and files that 
don't make maintenance easier.

Torsten

> Comments, please!
>
> 	-Inge
> _______________________________________________
> Marble-devel mailing list
> Marble-devel at kde.org
> https://mail.kde.org/mailman/listinfo/marble-devel



-- 
 Torsten Rahn

 Tel.: 0 21 61 - 46 43 - 192

credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz