Peter,

Thanks for clearing things a little further!

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!

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.

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 RTTI? Why should only TPersistent descendants have it? Class attributes is another missing part of the (language feature) puzzle. Why is it not supported by Object Pascal and FP? It really doesn't make sense to me. Unless, of course, this is so complex to implement...

I have hacked a way to get class attributes working- it does the job, but we should have a language construct to support this kind of thing. You can check this article to see how class attributes can be "implemented" the Delphi way:

http://www.latiumsoftware.com/en/pascal/0049.php#2

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.

Thanks again!

Demian


Peter Vreman wrote:


#A. Does FP support other class hierarchies other than those
   starting at TObject? I mean, any FP object is a TObject,
   right? I wonder if it would be possible to create a new
   object hierarchy from scratch, not based on TObject.

This is not supported. The compiler requires knowledge about TObject for things like AfterConstruction and BeforeDestruction.

#B. Reflection support, as far as I understand, starts at
   TPersistent and relies on published properties. Is there
   any chance this could be made more flexible- I mean, let
   TObject properties support reflection?

That will break compatibility with Delphi. Compatibility with Delphi is the most important issue, because that is what ppl expect how things work.

#C. Is there (planned) support for class attributes?
#D. Is there (planned) support for class templates?

When it is not in Delphi then it is not (planned or) supported


#E. Is there (planned) support for wxWindows? I think this
   is a terrific abstraction layer for GUI. The best is
   that it is stable (10+ years), works on many plataforms,
   and as FP/Lazarus, it is OS. But it still doesn't have
   a Pascal port.

The core developpers have no time for creating the bindings. But if somebody else creates them we can include them.

#F. I haven't seen any links or pages through which I could
   volunteer to help with FP/Lazarus- where do I find that?

You can use the mailing lists. When you help FPC/Lazarus with a lot of patches you can get cvs write access. There is no standard procedure, it is not a professional job for which you have an interview and to sign a contract.


Peter


_______________________________________________
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to