Re: True Name Spaces, when?

I totally agree with you.

The binary compatibility across versions of Delphi is a must.

Robert Giesecke wrote:
Henrick Hellström wrote:

Interesting idea, but would it work? Either the first or the second pass would have to perform the syntax check: Programmers don't magically avoid typos just because the compiler is two-pass. Problem is, when a unit interface section would be parsed the first time, the parser would have to assume any identifier it doesn't recognize will be resolved in time for the second pass. It couldn't tell typos from types declared elsewhere, which obviously would slow down the syntax check of large projects.

"Elsewhere" would still be within the used namespaces. Thus probably not all types in your project.
Also, the typo thing. forward declares to work as well, do they? And *everything* the compiler gets to do its work is the type name.
If the compiler would pickup all type names in the first sweep, forward declares were a thing of the past, together with circular references.

And what about the dcu format? A safe bet is that the time difference between a compile and a build
would be reduced significantly.

Again, I do not think that compile times would be increased by doing this kind of a simple two-pass.

OTOH, I don't like the need for compiler version-dependent DCUs as well.
Having something like .Net's assemblies could be added as well. By that I mean libraries that contain all necessary meta data, so that you can directly compile against them, without the need to have the DCUs as well.
And these libraries should be upward compatible. A newer Delphi should always be able to use the libraries of older ones.
And an older version should always be able to compile against those of a newer version of Delphi, as long as no new meta data things were used.
The current format of packages is a joke, IMO. Currently it is much easier to use DLLs and interfaces instead of the versioning hell that is BPL.
.

Relevant Pages

  • 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: 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)
  • D7 revival? stirring the old pot + Delphi 64 suggestion
    ... The new compiler, but with the old IDE, the old help. ... You can check other areas of the site and poster stats, it's not that Delphi posters don't use .Net, it's just that they don't use Delphi for .Net work. ... As for the 64bit debugging, a CPU view debugger would be all that is really needed to get things started (this is for fastcode after all), no need for rich source-level debugging, inspectors, etc. early on. ... Validation could be two-ways: one in the fastcode challenge, another made via CodeGear private unit tests. ...
    (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)