Jump to content

Talk:Delphi programming language

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Peter.Maude (talk | contribs) at 18:44, 14 November 2004. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Afaik Delphi isn't even a programming language, it's the name of a Borland programming tool in which you use Object Pascal to program. In that case, the article title would be incorrect. And further... Why am I getting the impression that this text was ripped out of some advertizement broschure for Deplhi?

Untill last year the langauge was called Object Pascal and the IDE / product was called Delphi. Since Borland was making significant improvements on the langauge, yet again, to support .NET as well as other changes the changed the name to the Delphi langauge. This should probably be two different articles, one on Delphi Studio (the new name of the IDE product) and the other on the Delphi programming langauge. I didn't write the original article (I don't think), but AFAIK this is not based even loosly on any Borland adverts. I think that if the article were split in two then it would read better since one would be about a product while the other would focus on the langauge itself. The "features" and "selling points" could be isolated to the product article while the technical aspects could be in the language one. -- Jim
In that case, shouldn't "formally known as Object Pascal" be "formerly known as Object Pascal"? By the way, many of the (POV) "remarkable features" of Delphi sound like features that appeared in other languages long ago, in one form or another. (e.g. transparent getters/setters were in CLU 10 years ago). (With some of the features, I can't tell exactly what they mean; e.g. how does a "type safe method pointer" differ from an ordinary type-checked function or method pointer?) —Steven G. Johnson
You are correct on the formerly part. I fixed that. Feel free to NPOV the article any if you feel it is too POV. I don't have much emotional attachment to it. -- Jim 01:00, 7 Oct 2003 (UTC)
I made an attempt to NPOV it. What it could really use is a list of disadvantages. BTW, I removed "Support for latest technology and standards" from the advantages list, because it seems like a bit of an empty claim. Which new technologies and standards are supported? -- ComaVN 21:37, 16 Mar 2004 (UTC)
AFAIK the name change Object Pascal -> Delphi already predates the .NET extensions in D7. It's a sideeffect of a renewed focus (at least on PR level) on Delphi after the namechange from Inprise back to Borland. Marco van de Voort.
Slight correction: The name change was regarding the company's name, changing from the original Borland to Inprise, and then subsequently back to Borland. -- Stevietheman 19:03, 16 Jul 2004 (UTC)
Delphi's/Object Pascal's main adversary is C/C++. Most claims (the type safe proc-pointer) must be seen in that light. Personally, I think the outdated library design (even though the VCL is quite cool) are a bigger problem than the language. E.g. the possibilties of interfaces were never exploited in newer versions of the VCL Marco van de Voort
I also don't like the .NET angle that has been added. Delphi and Delphi.NET are quite different, since only basic GUI and db operation can be .NETized easily (due to pointer and win32 use), and even for that, the VCL.NET framework is probably only temporarily supported for legacy reasons. All normal pascal code must be rewritten, and 3rd party components structurally updated for .NET. Maybe a split in a Delphi and Delphi.NET page (that reference eachother) is wise. Marco van de Voort
Wasn't there also an Apple dialect of Pascal called Object Pascal, with different extensions than Borland's version? Does anyone know enough about this to comment?

Yes, it was even formalised into an Object Pascal standards draft. Borland based on this draft for Delphi (though it kept _some_ compability with the old TP objects too). So Delphi is more or less a Borlandified version of that Apple dialect (I have Think Pascal manuals, and the dialect for objects is the same) Marco van de Voort


Delphi programming language vs. Delphi sofware development enviroment

Should these topics be separated? There's an article about Pascal, but it doesn't discuss extensions made by Borland (object-orientation).

  • Object orientation is not just a Delphi extension. TP has it too. Several other dialects too. There even was a O-Pascal draft standard. (IIRC proposed by Apple). Also the language is quite changed going through (soon 9) versions.
  • I think separating the lemma into .NET and native is better. These are quite incompatible to the point that they are actually separate (but related) products. D.NET breaks code that worked since TP3, and even on non Borland Pascals

-- Marco van de Voort.

And I really hate to see Delphi categorized as .NET language. It isn't, not even close. Common code doesn't compile under .NET, only thoroughly .NETified or trivial code does. ... And strangely enough it is not categorized as object oriented. If C++ is OOP, so is Delphi. Marco van de Voort

I removed the garbage collection notes because nearly every lined contained a flaw, amongst others:

  • Garbage collection does not require a VM/bytecode concept, even if .NET and Java do so. So it being dependant on the platform is incorrect. According to the standard, even C++ can be fitted with GC, and still be standards compliant.
  • Languages _are_ affected by what they run on, due to what they specify over pointers, timeframe of destructor execution etc. Plain Delphi has pointers, they had to be pruned to make a .NET language variation.
  • Moreover Java can be compiled and be Java VM less.

Or in general: the paragraph was about how Java/.NET do it, not about GC an sich. And notes about Java/.NET CLR explanation doesn't belong here, see their respective pages for that. Marco van de Voort

I added the section on GC as I thought it not fair to flag up a language as deficient for not having garbage collection. Hence the reference to C# and Java both of which use the platform and not the language to achieve GC. In other words although there are languages which compile with GC built in you do not normally expect a compiled (as opposed to interpreted) language to handle garbage collection. The very nature of GC is something you DON'T have to do.