On 2010-07-01 00:30, Marco van de Voort wrote:
It is a devilish dillemma.
It defintely is.
But, the whole process of evolution is just that [and, no, for this
once, I am not out to start a 'creationism' vs 'evolution' war here ;) ]
Being lax, and you become dumping ground for failed experiments of people that
lose interest, and the main project will suffer. We already have a packages/
dir to prove this for the other libraries.
I think I fully understand Core's concerns: It simply does not make
sense to destabilize the whole project after some adventure.
And, any code that gets into the main distribution should be such that
it proves it is an essential part of it --i.e. it is worth having and
worth maintaining.
A fork for a while might be doable, and it wouldn't brake the new team with
constant stability and compatibility requirements etc.
This is, IMHO, the best response one can expect. Implicit in this
temporary fork should be the understanding that as long as the fork is
considered better (I know, a subjective thing) and that it is backward
compatible (or, with the absolute minimum --and/or understandable--
incompatibilities), the fork will be given due consideration for
inclusion/acceptance in part or in full. IOW, forks should not end up
being wild goose chases.
Not wanting to plunge the project into a chaotic rewrite has nothing to do with
commercial interests. If there are reasonable doubts about the success of this
attempt, it is only logical that Core doesn't want to upset the project for a
long time. And then there is the issue of possible speed degradation.
Asking for a rewrite of a running project would be insane --not that
such insanity has never been in SW world (Netscape comes to mind)--, and
we need to avoid that. A better solution would be a fork (or a parallel
project).
I think these "pie in the sky" kind of scenarios are several years if not longer beyond
the initial C compiler. It will be a plant that needs a lot of nurturing and care for a very long
term, before it becomes an alternative, and faces stiff competition. And there is another problem
that the "pie in the sky" scenarios seem to be the main reasons for the compiler, so it
will require quite a pigheaded team.
Of course, such stretched scenarios will take time --if they ever
materialize. But, we can never know; perhaps there's already someone
brilliant enough in the crowd here who's looking for some such feat pull
and later use it as part of his/her CV.
If these rosy C helps Pascal interoperability scenarios are possible at all.
Kylix uses Pascal bindings to libc, despite Borland having a (compatible!)
C/C++ compiler. And C++ compatible Delphi code is stuffed top till bottom
with {$externalsym xx} and similar helper commands
I am curious: Since compilers are your domain, allow me to ask: Do you
think Borland did that (peppering code with '$externalsym xx ' stuff)
because there was not other/better way? And, if you had a truly
compatible C/C++ compiler, would you end up doing that too?
Cheers,
Adem
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
