Re: Delphi - What needs looking at in .NET, and ok the namespaces again

Chad Z. Hower wrote:
Ok - since someone asked, I'll start posting them one by one. First
entry is there too, and its namespaces. :)

http://www.kudzuworld.com/blogs/DelphiNETbar/

Interested to know what changes could be made to Delphi to work better
with .NET? Here is a dynamic and updated commentary, blow by blow.


Nice idea! :-)

I can't comment on your article (or I am too stupid for it *g* ), so I'll comment here.

The namespace issues could be solved very easy and in an elegant way, methinks.
First, there's no need to *force* Delphi.Net to "use" units.
Both usages should be possible. The classic unit name based uses clause or the .Net-ish namespace uses.
When having a D.Net unit "Some.Namespace.Unit1" one should be able to use it this way:
uses Some.Namespace;
or
uses Some.Namespace.Unit1;

Then, the unit attribute which all D.Net classes are marked with, is basically unnecessary.
You could add all *meta data* right into the assembly manifest.
There you could place the information which class has been placed in which unit.
Another thing to put there would be things like public type aliases.
Now, the compiler knows what "units" are inside a D.Net assembly and which type is declared in which unit.

The point behind this is, that there should be no need to reference the RTL lib (Borland.Delphi.dll) without using anything from it on purpose.
Also there should be a compiler switch which enables or disables things like the creation of meta classes for every class, and it should be switched off by default.
Now, a new Delphi.Net package w/o any Delphi specific RTL stuff (like meta classes) will have no reference on a specific RTL lib. Thus you could use Delphi.Net assemblies, compiled from different compiler versions.

Would be a good start to be a lot less painish than the current compiler.
.

Relevant Pages

  • Re: borderstyle in construction
    ... > now the compiler gave an error like: ... would say you were missing the wrong namespace... ... but Delphi does not ...
    (comp.lang.pascal.delphi.misc)
  • Alternative Future of Delphi?
    ... relevant compiler or interpreter... ... No more intricate code generation required for a particular platform ... on the Delphi compiler side. ...
    (borland.public.delphi.non-technical)
  • Re: Which Delphi Version To Buy
    ... Given the fact that Delphi compiler is quick and small, do you see feasible having a runtime compiler/parser enabling what you describe above? ... For example the basic data types processing in Delphi is sensibly superior to .NET's one exactly because is closer to the iron. ... Well, for parallel programming I, for one, certainly feel the need of a VM simply because the actual CPU architecture is far from the way in which humans deal with the reality which is parallel. ... The vast majority of the games you have to deal with /different/ characters doing /different/ actions in parallel, responding each one to the stimuli which comes from the environment. ...
    (borland.public.delphi.non-technical)
  • Re: Compiler optimisation
    ... > Keep in mind that Delphi is one-pass compiler. ... > limits number of possible optimizations to ones that do not operate ...
    (borland.public.delphi.non-technical)
  • Re: Version after Version
    ... merely because Delphi has no 64-bit compiler? ... >> targeted instructions and increasing the size of the cache to 32,000 ... >> That has nothing to do with the number of address lines on the CPU ...
    (alt.comp.lang.borland-delphi)
Loading