[fpc-pascal]FP newbie

[Marco van de Voort]

> I'm a FP newbie but a long-time Delphi and Pascal developer. I'm curious 
> about several things regarding the current state of FP as well as its 
> future. Since I'm considering the use of FP in classroom for my students 
> and also for commercial development, I hope some of you could help me 
> clear some things in my mind.
> 
> #1. Is there a white paper on the features the FP compiler supports and 
> the features it doesn't support when compared to the Delphi compiler? I 
> know I can dig this info on the manuals but I was hoping to find a 
> feature matrix indication the major diferences and similarities between 
> the FP and Delphi compilers.

No there isn't. The older 1.0.x series is a mix of D2 language with some later
extensions, and a mix of a bit newer RTL (D4, though some parts at D2 level).

The newer series that just went into beta (1.9.x as beta, and will be 2.0.x
at some time) will be close to later versions (up to D7) compatible. 
However while already stable and usable, not all more exotic features have been
tested, documented or even completely implemented.

The only major language element completely missing afaik is dispinterface, while
several other are incomplete.

While e.g. some base fundamentals for packages have been implemented in the
compiler, the related runtime parts have not been created yet.

We find missing smaller functionality in the RTL nearly everyday, but that
is partially also because this version went public only a week ago, it is
the initial rush. 

> #2. Does the exception handling architecture provide easy to the call 
> stack and other potentially useful information about the exception?
 
> #3. Is there (planned) support for object serialization?
> 
> #4. Is there (planned) support for object persistent (like J2EE 
> container based persistence)?

I'll let these pass.
 
> #5. Is there (planned) support for garbage collection on objects and/or 
> pointers?

It doesn't make much sense to create a compiler for an efficient, static,
language, and then slow it down by mutilating it with a dog slow GC.

There has been some academical interest/discussion in trying to make a proof
of concept hierarchy (so a separate object hierarchy not based on tobject)
that can be garbadge collected, but that certainly plans to do that outside
the current classes hierarchy, with no or minimal compiler support.

However all people that were discussing that are much to busy for that, so, unless
an external contributor pops up, don't hold your breath.