I was on freenode irc #fpc earlier and asked some questions but not enough people were…
Show quoted text 7 lines
Nobody can predict if sometimes in the future somebody will contribute a patch regarding this.

Mailing lists / fpc-pascal / 2010-04
14 messages · 6 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
I was on freenode irc #fpc earlier and asked some questions but not enough people were…
Nobody can predict if sometimes in the future somebody will contribute a patch regarding this.
When I google search for "FPC generics" tohe top result links here:…
I told you this already months before. type generic is a compromise because there was even the idea to make generic an own section like
var
...
type
...
generics
...
Technical limitations aside, at this point what would be needed from the community to get…
Technical limitations aside, at this point what would be needed from the community to get the generic syntax changed?
1) Delphi mode only
2) not breaking old code i.e. accepting both variants
3) more Delphi generic compatibility
I was on freenode irc #fpc earlier and asked some questions but not enough people were online to get an answer.
My question was/is:
**** Will there ever again come a point where FPC attempts to bring in more compatibility with Delphi? Specifically, in regards to operator overloading and generic language syntax. ****
I'd really like to use generics in my cross platform graphic widgets toolkit and have it continue to work with both Delphi and FPC, but as of right I can't tolerate the enormous amounts of {$IFDEFs} required to do so.
For those interested, here is a video showcasing a very old version (circa
2004) of my toolkit. Compiles on Windows (Delphi 7) and Linux (FPC).
http://www.youtube.com/watch?v=iqeFZ2zhszU
Screens from my picture browser (circa 2006) :
http://imagebot.org/snapshops/photo-grid-animate.jpg http://imagebot.org/snapshops/3d-picture-gallery.jpg
Nobody can predict if sometimes in the future somebody will contribute a patch regarding…
When I google search for "FPC generics" tohe top result links here:
http://wiki.freepascal.org/Generics
Two cases:
1) type generic TList<T> = class // ... as is now, the word generic is redundant
2) type TList<T> = class // ... better and in line with Delphi
It seems both were on the suggested list. How did version case 1 win out? To me it would seem that pascal has always been about:
[type block] [identifier] = [type declare] ;
[const block] [identifier] = [const declare];
[var block] [identifier, [identifier, ...]] : [var declare];Where identifier was always the first token to begin a type, var, or const block. Oh well, I hope someday we can revert Free Pascal the language to case 2.
I told you this already months before. type generic is a compromise because there was…
Technical limitations aside, at this point what would be needed from the community to get the generic syntax changed? Supposing I had the soruce code changes to accommodate the change to remove the "generic" keyword, what would be needed from the community to approve moving that change into the language?
When I google search for "FPC generics" tohe top result links here:…
To be honest, this is a slightly unfair case, saying Free Pascal must become Delphi compatible, when Free Pascal had generics support *before* Delphi did. Maybe Delphi should become more Free Pascal compatible.
It seems both were on the suggested list. How did version case 1 win out? To me it would seem that pascal has always been about:
I can list quite a few examples where Delphi breaks the "normal pascal like" syntax too. Yet nobody complains about that.
Our company also wanted to have common code and be able to switch between Delphi and the Free Pascal compiler. But then we simply came to the conclusion that Free Pascal is an excellent compiler on its own, and we really don't need Delphi support any more. We made the switch 5 years ago (to only work with Free Pascal), and have never regretted our decision.
I just think the "being delphi compatible" every step of the way, will hold Free Pascal Compiler back, having to always wait for Embarcadero to catch-up with what developers want (and we know how slow Delphi can move - last few years showing this). And that means Free Pascal will *always* be one step behind. Free Pascal is powerful enough to stand on its own. It has many unique features Delphi cannot compete with. Simply switch to Free Pascal as the only compiler and continue to take advantage of what FPC has to offer.
Just my 2c worth.
Graeme:
"To be honest, this is a slightly unfair case, saying Free Pascal must become Delphi compatible, when Free Pascal had generics support *before* Delphi did. Maybe Delphi should become more Free Pascal compatible."
I've preemptively disabled this argument so many times in the past. It's become passe.
Really? I didn't see a single patch of you so far.
Technical limitations aside, at this point what would be needed from the community to get…
In our previous episode, Anthony Walter said:
Technical limitations aside, at this point what would be needed from the community to get the generic syntax changed?
Patches.
"Technical limitations aside, at this point what would be needed from the community to get the generic syntax changed?:
: Patches.
I believe there would first need to be some sort ofg consensus within the community about the changing the syntax.
Anthony Walter wroteI believe there would first need to be some sort ofg consensus within the community about the changing the syntax.
If both syntaxes are supported I don't think many people will be against it.
Question: who wants to add it?
"Technical limitations aside, at this point what would be needed from the community to…
In our previous episode, Anthony Walter said:
I don't think this is necessary (the Delphi mode is for delphi compatibility, and till now even half decent patches that improve compatibilitiy have been accepted), and changing is not an option since that unnecessarily breaks compatibility.
Adding the Delphi syntax to Delphi mode would be enough.