Marco van de Voort
marcov at stack.nl
Thu Nov 13 15:34:13 CET 2003
> I see that many responses refer to Delphi compatibility. I understand
> that the FP compiler has a switch that tells it to compile the pascal
> code as Delphi code. In that sense, I'd expect FP to provide a superset
> of the Object Pascal dialect. And that is true indeed!
There are some extensions yes, and in the future, foreign OSes and
processors might cause some more extensions.
However in general we reluclantly add features, usually because the
main argument from most people is "it would be nice to have ....", and
there are many more reasons not to (clean language, less features means
more time spent on stability etc).
> FP offers operator overloading, which is not an Object Pascal feature.
> I'm not yet familiar with the compiler but I guess many other features
> are also particular to FP.
Never versions of Delphi offer it.
> Many of us (Delphi/Kylix developers) find many features missing in the
> Object Pascal compiler and we see FP is a real chance to get those
> features working. RTTI, for instance. Why shouldn't all objects have
> Why should only TPersistent descendants have it?
It sounds like an efficiency reason.
> Class attributes is another missing part of the (language feature) puzzle.
> Why is it not supported by Object Pascal and FP?
That's the wrong question. The good question is "what would be the use?"
I see two reasons in your article,
The first is class instance counting, for which I, and I'm no OOP hotshot,
can already name two solutions
- use a factory pattern, or
- a global var in the implementation
part of the unit that implements it, and that is atomically updated by
create and destroy.
and there is no added benefit to have the properties in the language for
this example, except the minimal benefits of datahiding. (actually the data
is properly hidden if you only put that class in the unit, all constructs
can be abused. I can also keep a pointer to class attributes)
The second solution is even a general workaround for class properties.
The second reason (association of an object instance to the class as a whole
(for management purposes), is actually the same thing more or less.
Both can be solved properly, and personally I find the workaround presented
in the article uglier than the simple variable in the implementation of
FPC is about providing a production compiler, not to do language research,
so added features must have real use.
> It really doesn't make sense to me. Unless, of course, this is so complex
> to implement...
It is certainly _very_ complex to implement I think.
> It's good that you pointed out early that the main thought here is to
> keep Delphi compatibility. This way I won't dream of features that will
> "never" be part of FP.
More important is the Pascal background I think. The Wirthian languages
always were relatively small, consistent and clean, and usually the argument
is that this makes compilers easier to implement, and avoids nasty side
effects, which you are bound to encounter when programs get big (read way
over a hundred thousand lines)
Baroque syntax doesn't originate in the Pascal camp :-)
I know a lot of the new open source scripting languages like to have a lot
of features. How many _really_ large programs were written in them?
More information about the fpc-pascal