[OSRS-PROJ] Interface ideas for Proj4

Martin Manningham martinm at six.net
Tue Mar 28 18:37:13 EST 2000



Jan-Oliver Wagner wrote:

> Dear Martin,
>
> On Mon, Mar 27, 2000 at 07:35:13PM -0500, Martin Manningham wrote:
> > the current API backward compatible, but we must create a new API, in
> > C++,
>
> your ideas about the API sound interesting. But I must say
> that C++ should better not be used for the base development.
> It makes sense as wrapper to include proj in your own C++
> program.
> It is less optimal for the base code, because proj is free software.
> Frank Wamerdam currently volunteers as a maintainer, but other
> people may follow. Additionally, co-authoring man power could be
> be attracted. C++ is a less spoken and more complicated language
> than many others. It is good for people who have a single
> project done in a closed working group being involved deeply
> (often the case for proprietary development).
> For people jumping from software to software adding their
> source code, fixing bugs it just takes time to understand the code
> and hence they will spend no efford or even choose an alternativ
> product.
> Popular examples where C++ code has been a major problem: guppi (switching
> after 1 year of desertion to C has vitalized development)
> and mnemonic (which has the potential to beat netscape and msie, but
> the main author seems unable to interest people to support in C++
> programming).
>
> I know that Frank Wamerdam ist one of the guys who are
> very good in C++. Honestly I must say, that (though I have
> done large projects in C++) I don't feel comfortable and efficient
> when trying to program in C++.
>
> Cheers
>
>         Jan
>
>

I understand your concerns about the use of C++ in this kind of project,
and your comments and experiences are helpful. However, the main
advantage of object oriented projects is flexibility and is easily
updatable, things that are somewhat a lot more difficult to do if the
project was written in C. As an example, how could you expect to easily
add a datum management in the API without adding more and more
functions?

This is a common problem with well design systems, the first version get
a very simple and easy interface. But, with time, new functionalities
must be implemented and things are getting more and more complex. In the
end, if this evolution is badly managed, the system become a complete
spagetti. Of course, PROJ4 is far from that, but many commercial
applications follow this bad trend.

Regards

Martin
----------------------------------------
OSRS PRoject PROJ Discussion List
To Subscribe: send a message to majordomo at remotesensing.org with 'subscribe osrs-proj' in the body
To Unsubscribe: send a message to majordomo at remotesensing.org with 'unsubscribe osrs-proj' in the body
To Report Problems: send a message to owner-osrs-proj at remotesensing.org



More information about the Proj mailing list