Hi,

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.

#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)?

#5. Is there (planned) support for garbage collection on objects and/or pointers?

I think that will do for now. Thanks,

Demian

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.

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.

Thanks for replying!

I get the picture- it's a neverending work indeed! But I guess when the Lazarus IDE becomes a production software, the interest in FP will grow and will allow the project to run faster.

I can tell as one of the moderators of the largest portuguese speaking groups on Yahoo! Groups (2200 subscribers) that if Lazarus were already available as a stable release on Windows and Linux, it would draw the attention of many, many users.

Also, in the academia, I'm sure most institutions would choose FP over Delphi for their first year algorithm and programming logic classes, and second year OO programming- I would do that with my students!

ok... guess the answer would be no, then!

OK, I understand you point. This leads me to another set of intriguing questions.

#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.

#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?

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

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

#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.

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

Thanks again for your response!

Regards,

Demian

FP Team, I think we really need a document outlining the feature matrix of the compiler(s).

If someone sends me the correct list, i'll LaTeXify it. anybody ?

cheers,
-Krish

Hi!,

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

Do we really need templates ? IMO, templates and reference based objects dont go too well.

wxWindows is a good library/framework indeed. But why do we need a pascal interface to it ? It adds too many layers to the whole system. eg: to create a button => pascal-layer->wxWindows->gtk+/motif/win32->window system window.

Do we really need these layers ? (wrapper wrapping a wrapper wrapping a wrapper !!!)

OTOH, what we really need is an emulating toolkit atop the native window system (a la FLTK).

cheers,
-Krish

>> #2. Does the exception handling architecture provide easy >> to the call stack and other potentially useful information >> about the exception?

Yes, the frame pointer is passed

Not everybody knows all parts of the compiler/rtl/fcl. These are FCL questions that michael or maybe one of the lazarus ppl can answer better.

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

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

Hello again -

Still testing the new 1.9.0 beta compiler (Win32), I have come across another issue which is much easier to demonstrate:

Take the following program:

program asmtest;
procedure   myasmstuff;
var
   BOB : dword;
begin
   asm
      mov   eax,BOB
      xor   eax,eax
      mov   BOB,eax
   end ['eax'];
end;
begin
   myasmstuff;
end.

If I compile this using PPC386 at the command line (default configuration file) like so:

E:\Projects\tests>ppc386 -Rintel asmtest
Hint: End of reading config file e:\pp\bin\win32\fpc.cfg Free Pascal Compiler version 1.9.0 [2003/11/05] for i386 Copyright (c) 1993-2002 by Florian Klaempfl
Target OS: Win32 for i386
Compiling asmtest.pp
Linking asmtest.exe
16 Lines compiled, 0.5 sec

No problem, it compiles and the program runs without any output (as expected).
But a small change to the command line [adding the -S2 switch], like so:

E:\Projects\tests>ppc386 -Rintel -S2 asmtest
Hint: End of reading config file e:\pp\bin\win32\fpc.cfg Free Pascal Compiler version 1.9.0 [2003/11/05] for i386 Copyright (c) 1993-2002 by Florian Klaempfl
Target OS: Win32 for i386
Compiling asmtest.pp
Compilation aborted asmtest.pp:8
Runtime error 216 at 0x004CF77E
0x004CF77E
0x004437D9
0x004438DB
0x00443C34
0x00479DFB
0x0047B662
0x0047BB75
0x0047BE30
0x00479C90
0x0047B662

Is the order of switches on the command line (same thing happens if I modify the FPC.CFG file) supposed to be significant?

If I put the -S2 switch before the -Rintel switch, it compiles with no problems....
If I use the -S2 switch *by itself*, I get the RTE 216 again (as opposed to a list of assembler instructions not recognised, as I would expect)....

And on the positive side, for my existing code that the new version DOES compile, it makes a much smaller EXE (e.g. 75kb instead of 110kb). This is fantastic! I can't wait for the remaining bugs to be removed and 2.0 to be released...

Lawrence.

Or the foundation classes of Lazarus, LCL.

Marco,

Let me see if I understand your concern...

>wxWindows is a good library/framework indeed. But why do we need a >pascal interface to it ? It adds too many layers to the whole system. >eg: to create a button => pascal-layer->wxWindows->gtk+/motif/win32->window system window.

How does LCL work- doesn't it abstract the widget set as well?

LCL Button -> LCL Abstraction -> Widget Set -> Windows System

Now, correct me if I am wrong- what is *exactly* the difference? My point of view is that by developing a wxWindows GUI, Lazarus would benefit from a mature and well organized abstraction layer- that is it. I know that I could build a wxLCL and offer it to the community sometime in the future. I just wanted to know why build yet another Window System abstraction layer when there is good, mature, stable, and fast options around. Many Python users, for instance, are moving away from their older GUI libraries/toolkits to wxPython.

Isn't FLTK something just like wxWindows? I mean, FLTK is just a toolkit and one would expect it to be much less complex than wxWindows, which is a full GUI framework. In the end, both come down to API calls so on the developer's point of view they'd be the same on a coding perspective...

Or the foundation classes of Lazarus, LCL.

The discussion is exactly about how LCL supports native widget sets.

Demian

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

Marco, Let me see if I understand your concern...

Most of the things you replied to aren't my comments, anyway.

Your assumption that on Windows there is a window set involved.

While the picture is ok for e.g. Linux, (mainprogram->LCL->GTK->X-Windows), on Windows LCL interfaces directly to win32 (mainprogram->LCL->Windows)

My point of view is that by developing a wxWindows GUI, Lazarus would benefit from a mature and well organized abstraction layer- that is it. I know that I could build a wxLCL and offer it to the community sometime in the future.

Widget sets can be added to the LCL, so I don't think Lazarus will have a problem with including a donated wxWindows backend Wxwindows would be in the place of gtk so it would be

mainprogr->LCL->wxWindows

(and then wxWindows internal dependancies)

I just wanted to know why build yet another Window System abstraction layer when there is good, mature, stable, and fast options around.

The LCL is much more than a widget set. It is the base building block of a RAD system. And also it quite Delphi VCL compatible in spirit (to allow easy porting).

Moreover wxWindows is relatively recent. It wasn't around in a stable form when Lazarus was started.

Why I'm lukewarm about wxWindows at best is that all widget sets that are on multiple platforms all say the same thing as you now. (like e.g. GTK)

Many Python users, for instance, are moving away from their older GUI libraries/toolkits to wxPython.

That doesn't really confort me. If I made choices like a Python user, I would be programming Python not Pascal.

Lazarus/LCL goes a step beyond that. It is a full RADable framework, which is fully native on Windows, without external libraries.

But I'm no lazarus member, so if you want more precise reasons, I suggest you join lazarus' maillist.

RTTI is enabled by a switch {$M+} and it is also inherited by descendant classes.

That is already supported by an fpc extension allowing static members. Just add the static directive after the field.

As to that, the answer is simple: RTTI for all objects would blow up your executable. RTTI information takes up a *lot* of space in your executable. It's a burden, and people who don't need it should have the chance not to use it. This is impossible if you force RTTI in TObject.

Since TPersistent descends directly from TObject, I don't see the problem. If you need it, descend from TPersistent. If you don't: descend from TObject.

Michael.

Strange. As far as I know, it was around and used way before Lazarus appeared. It was already around at least in 1995, even before the first release of FPC...

Which doesn't invalidate any of your arguments, of course. Just a historical note.

Michael.

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.

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 the unit.

----

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?

In a usuable state to build Lazarus on top of I mean? The first time I heard about it was 1997 I think, and then it was advocated as a small clean way to make portable apps, no complete framework.

As far as I remember it, it would have been enough to support Lazarus. Maybe not the complete widget set, but definitely most of it.

Michael.

RTTI is enabled by a switch {$M+} and it is also inherited by descendant classes.

Just like Object Pascal...

That is already supported by an fpc extension allowing static members. Just add the static directive after the field.

ok, another feature not found in Object Pascal!

Thanks,

Demian

Michael,

I see your point... I think perhaps what I was thinking about was RTTI coupled with some kind of smart RTTI linking- I mean, all objects would have RTTI info but that info would only be included in the EXE for those objects that are "touched" by the code.

In Delphi, RTTI is mainly used for the streaming of form resources. I have used it for other implementations, such as object serialization and database persistence of objects. So, I know that if RTTI was part of all classes I would have had a much cleaner design of my framework and many more classes would be "natively" supported.

Since TPersistent descends directly from TObject, I don't see the problem. If you need it, descend from TPersistent. If you don't: descend from TObject.

Yeah, you're probably right. I can live with that! ;)

Thanks,

Demian

... or "touched" by data. And that is always the case. There is a reference from the Class data/vmt to the RTTI. The result is that it'll then always be included when the Class is used.

That is a very good point and I'm inclined to agree with you.

Guess I should read the manuals of the newer versions because I missed this new feature...

I think you missed the point of the article. I had no intention to list the benefits of using class attributes. I just wanted to share a technique that would enable developers that wish to use class attributes to be able to use them.

In my opinion, class fields/properties do bring about many benefits. Not only do they allow data hiding on the class level, they also allow global values to be bound to their classes, and not left outside the class code. A value you define that is only meaningful in the class context should in fact be encapsulated in the class. Also, and perhaps this is a big point to note, using global or unit local variables is questionable OO programming technique. If you really wish to develop in OO style, you will stay away from globals and try to keep all your class data within your class definition, and all your object data within your object instance.

FPC is about providing a production compiler, not to do language research, so added features must have real use.

agreed.

but new features will always come along- it is inevitable. the secret is knowing what is worthwile supporting in new compiler versions...

I see your point...

Thanks,

Demian

ok, another feature not found in Object Pascal!

Be careful here... FPC implements Object Pascal too. Say 'Delphi' if you mean Delphi. Object Pascal in son eclusively Borland (though they originated it in it's Delphi instance.)

Matt

AFAIK the main reason, why the gtk interface for the LCL was started, was simply, that the devels had experience with gtk, but no one had experience with wxWindows.

Any volunteers to start the wxWindows interface for the LCL are welcome.

Mattias

Nice and stylish, but still no practical reason.

That is exactly why I use a "multi-paradigm" language like Object Pascal, because I'm able to use the strengths of those.

If I want to use pure OO, I'll use SmallTalk. OO is a tool, not a religion.

That is exactly the reason why I'm having this discussion. There have to be benefits, rather than just stylish correctness.

I'd rather have the time spent on e.g. generics (what C++ calls templates), which are also fashionable, but at least I can view them as a serious tool.

FPC needs these discussion even more than e.g. Delphi. Borland can commission a couple of programmers for a year to follow what turns out to be a dead end.

For FPC, that same "year" is much longer, since the developers do this part time. Adding rare used features.

This is also a reason why FPC is not embarking on some .NET or Java bytecode adventure.

Afaik is Object Pascal an Apple invention, which was submitted as dratf standard for standarisation

Borland took that and modified it for Delphi. (and probably adapted it to TP/BP style)

But some Mac user (/me smells a Jonas) will probably correct me :-)

Object Pascal in son eclusively Borland

Translateion - "Object Pascal is not exclusivly Borland"... um yeah, new keyboard people ;-)

Afaik is Object Pascal an Apple invention, which was submitted as dratf standard for standarisation

Sure, that is why I said they 'originated' the *Delphi* version, not the lannguage... Think Pascal does Object Pascal, as do older MPW compilers and MW too till they dropped support.

Matt

Marco,

I'm not debating whether a feature should or should not be considered for inclusion in FP. It just occurred to me that class attributes are constructs that have *real* use beside just stylish correctness. Class methods have been implemented, right? Aren't them just as equivalent to global procedures and functions as class fields are to global variables? BTW, Peter replied to my message saying that class fields are supported through the use of the static directive.

I know that an OS initiative such as FP should invest its time in the development of features that will bring the most benefit to a larger share of the community. Things such as bringing compatibility with Delphi, making the compiler stabler and faster, supporting more plataforms, and implement missing or unfinished functionality come to my mind. All I wanted to do was discuss possibilities and understand why a given feature was not implemented by FP and if it was being considered for implementation.

I do agree with you that when a "hybrid" language such as Object Pascal offers constructs that allow me to implement funcionality simpliar or analogous to those I'd implement using pure OO constructs on another language, other features deserve more attention because they will add more to the project.

I also won't debate which OO features are worth using/implementing. This will bring us down to our understanding and our personal opinions about the OO paradigm. Bertrand Meyer has written in his book Object-Oriented Software Construction that method overloading (syntactic polymorphism) is not such a great technique because it makes the source code hard to read and understand. Overloading itself is not an OO specific feature but many OO languages do implement it. As you see, it is questionable whether this is a good feature or not. I personally like to use it, and I use it with care but I understand the reasons why Mr. Meyer thinks it is not a good technique.

Anyway, thanks for the reply. It is always nice to share experience with knowledgeable people!

Regards,

Demian

Mattias Gaertner wrote

AFAIK the main reason, why the gtk interface for the LCL was started, was simply, that the devels had experience with gtk, but no one had experience with wxWindows.

I'm stretching my memory here but as Marco indicated, wxWindows wasn't mature at the time. Also if I remember it didn't deal with signals well at all. Secondly at that time it did not support GTK. It only supported Windows and some Xt and Motif.

It is also written in and for C++. Sooooo this is what we would have been doing.

The LCL needs to be not only widget set independent but platform independent. If we wrote the LCL just to wsWindows then we would eliminate the possibility of using Lazarus on other platforms that FPC supported. So we made an abstraction layer between the LCL and the GUI widget set being used. So using wxWindows for GTK would mean.

LCL -> LCL/interface -> C++ wrapper -> wxWindows -> GTK+

Not only would we have to write the interface for wxWindows but it would have to be a wrapper around C++ since FPC doesn't support C++ directly. Alot of extra work instead of going directly to GTK. Besides as I stated wxWindows didn't support GTK at the time. This would have been wxWindows 1.0 and you can still see what it supported by going to the their web site.

What is that LCL Abstraction ? It should read
LCL Button -> Widget Set -> Window system.
This is one layer less.

Python and Object Pascal are different beasts.

FLTK is really light. It requires only basic window creation and a simple mechanism for passing events. It draws its own widgets. Moreover, the widgets are lightweight - they don't require native windows for widgets.

> Or the foundation classes of Lazarus, LCL.

I have'nt looked at LCL so I can't comment on it. But if it is good/solid, people should get behind it and support it. Does it support automatic layout management ?

The discussion is exactly about how LCL supports native widget sets.

wxWindows is a C++ framework - so its design is oriented towards it. Take a look at how event handling is done in wxWindows. Why should Object Pascal use its (rather ugly) event handling mechanism when it has a (relatively) beautiful mechanism in method pointers ?

If u r not convinced, try implementing the observer pattern (which is required by a general purpose event dispatch system) in C++ and Object Pascal and you'll be convinced.

cheers,
-Krish

But some Mac user (/me smells a Jonas) will probably correct me :-)

Yes, you are true. Apple contracts (is this the correct verb?) N.Wirth in 1982-3 to develop an Object Pascal language/compiler. MacOS was written in pascal and assembler from version 0 to 6.x.; System 7.0 and 7.1 was a mix of C/C++, ObjectPascal and Assm 68k and since then C/C++ and assm 68k/PPC. Apple was "forced" to change to C/C++ because developers as Adobe, Macromedia, etc... wanted it

As a personal note i found, when C/C++ comes as the principal language, more instability, bugs and errors.

There are 10 groups of people, those who can count in binary and those who cannot
Hay 10 tipos de personas, los que saben contar en binario y los que no