In article <45115e86$
XXXX@XXXXX.COM>, John Moshakis says...
Quote
Jolyon Smith writes:
>Delphi.net clings desperately to it is Win32 past....
In what way, because I think that statement is rubbish
In many ways, but it won't take long for you to find out for yourself if
you actually look into it.
Here's a real big one: Units and Namespaces
So desperate was the need to remain compatible with the unit = file
model in Win32 Delphi, the implementation of units and namespaces just
doesn't work very well.
Not only that, but by preserving the old model AND clinging to the
single pass compiler, circular unit references are STILL a problem in
Delphi .net
Now compare and contrast with Chrome.
unit as a keyword is supported _only_ for backwards compatability and
is, afaics, now synonymous with the namespace keyword.
Your source file declares which namespace it is part of (where
previously you had "unit XXX" you now have "namespace XXX") - Big
difference: Two separate files may BOTH contain "namespace XXX".
A file may also explicitly quality classes it defines as belonging in
_other_ namespaces.
Partly required by this immense flexibility, but also I guess
recognising that processors, and therefore compilation speeds, are
vastly improved over the state of the art in 1995, Chrome has also
dumped the single pass compiler.
Result - circular unit references are no longer a problem. They simply
aren't an issue.
I'm sure I don't need to expand on just why this is a HUGE leap forward
for Object Pascal.
There are plenty of other aspects of pre.net Delphi that don't quite add
up in the .net world, but it is not my job to list all those for you
here. Instead I suggest you do a bit of research yourself.
Here are a couple of resources to get you started.
This one draws back the curtain on the IL code generated by Delphi.net.
There are some unsurprising revelations (unit initialization and
finalization support requires plenty of smoke and a number of mirrors)
and some rather more suprising ones (Delphi properties require an
additional layer of code to make them work in a .net way!):
www.cakesolutions.net/pdfs/delphi-il.pdf
This one is an interview with I guess the main guy behind Chrome
(RemObjects - a noteworthy player in the Delphi area). In it he deals
with the question of "Why a new Object Pascal for .net":
www.bitwisemag.com/copy/programming/chrome/hoffman_qanda.html
The past 2 days have been revelatory for me.
I've never really felt comfortable with Delphi.net but could never quite
put my finger on why. Having now seen Chrome and been prompted to dig a
little deeper into why Delphi.Net is the way it is, it is starting to
crystallise.
Delphi.net is essentially contriving to be backward compatible with
previous, non-.net Delphi. that is great if you are looking to do a no-
brains-required port. But .net is so vastly different from Win32 that
you are going to have to engage the grey matter at some point.
And at that point the pre.net legacy starts to feel more than a little
uncomfortable.
Lest we forget, pre-.net Delphi was itself kept largely compatible with
Win16 Delphi!!!
The time had come for Delphi to make a break with it is illustrious and
glorious past.
Not a clean break - we didn't need a whole new language, but the
language did need to change quite significantly, in *exactly* the same
way that Pascal itself was changed to suite the needs of Turbo Pascal
and then Delphi, at the time.
I fear the language had become a little too precious (or perhaps simply
too unwieldy to change).
--
Jolyon Smith