Re: I really hate .NET especially inside Delphi

Jolyon Smith wrote:

In article <4522c7e4$1@xxxxxxxxxxxxxxxxxxxxxx>, Allen Bauer
(Borland/DTG) says...

So how would you propose that we preserve the implicit built-in make
logic without having some physical mapping?

The question answers itself - you can't preserve the implicit make
logic by moving to explicit make logic.

Yeah... you're right... I certainly coded the only available answer in
the question itself ;-)

The question is, would the move to explicit make logic bring any
additional benefits over the implicit system?

This is a thought/research excercise we went through at the very
beginning. Since all the tooling around the language is predicated on
this aspect of the language, it makes changing this behavior *far* more
expensive than just a few tweaks to the compiler. For example, if we
tossed the notion of linking in .dcuils in favor of *only* linking with
packages, maybe, just maybe a move to explicit make logic would work.
However, that is also giving up on, what we've found in our research, a
very important thing that our customers really cling to as a clear
advantage.


Remember, removing that functionality is not an option.

For immutable technical reasons (it simply can't be done) or for less
tangible reasons (we don't want to do it because...) ?

I think I answered a little of it above. Certainly there *are*
technical hurdles that would have placed too high a burden (and thus,
cost) on the entire tool-chain. There are also the intangible reasons
of having a very diverse, passionate, loyal, and vocal customer base
that probably would have been more than a little irked at loosing that
key point.

This implementation was certainly not
done without a lot of thought and consideration.

Which would suggest that the answer is the latter - you positively
decided not to do it, rather than having no choice.

Again, you seemed to have inferred correctly.

I have yet to get deeply into namespaces, but it seems to me that the
explicit make system of a language (like Chrome, to use an Object
Pascal .net example) increases the flexibility of the language no end
and improves it's credentials as a .net citizen.

Sometimes perceived flexibility can come at a cost... a cost that is
very hard to quantify. Rather than codifying into the language certain
constraints, that is left to the developers, who will invariably all
choose different variations. Some feel that certain constraints are
liberating, while others feel it stifles their creativity.

i.e. aiui - the ability to "inject" classes into a namespace other
than that in which the physical module containing that class is
implemented.

This was certainly a problem with the way namespaces were done in D8.
Now, it is possible to do exactly that. However, no .NET language
allows you to physically inject into the namespaces of a precompiled
assembly. There is also a *lot* of confusion between an assembly name
and a namespace. An assembly name has zero, none, nada, bearing on the
contained namespaces. The only similarity they may ever have is what
the developer(s) of that assembly have specifically done.

So when I write a class that extends a class in some other namespace,
I can put that class in the namespace it logically belongs in,
despite it being physically tied to a source file that is not part of
any project in that other namespace.

As long as the unit name maps to that namespace, you can put it into
any namespace.

aiui this is not possible with the Delphi.net approach?

Borland.Vcl.Classes.pas
Borland.Vcl.Forms.pas
Borland.Vcl.Menus.pas

All the classes in the above units will end up in the Borland.Vcl
namespace. You *could* create a unit Borland.Vcl.Jolyon.pas and it too
will place all the classes into the Borland.Vcl namespace.

But to return to the original question: How to preserve implicit
make logic (presumably for backwards compatability)...

Why not a project option?

Project -> Options -> Compiler:

[x] Explicit Make

(off by default for legacy projects, on by default for new projects)

:-)... I think I went into that above...

--
Allen Bauer
Developer Tools Group
Chief Scientist
Borland
http://blogs.borland.com/abauer
.

Relevant Pages

  • Re: Network namespaces a path to mergable code.
    ... So I think the abstraction that we use to access per network namespace ... Returning to implicit vs explicit function arguments, ... term we want a configuration option. ...
    (Linux-Kernel)
  • Re: Puzzling OO design problem
    ... > since you explicit allowed metaprogramming hacks :-), ... from version_1 import Namespace as PreviousNamespace ... George ...
    (comp.lang.python)
  • Re: Network namespaces a path to mergable code.
    ... patches just introducing namespaces for sockets in 2 ways: ... function parameters and using implicit current context. ... So I think the abstraction that we use to access per network namespace ... The explicit versus implicit lookup is just ...
    (Linux-Kernel)
  • Re: Designer generated code fails to compile
    ... I can tell you that you cannot get the tool to change it spots. ... is explicit should not matter. ... which is in this default namespace. ... How do I stop the designer from setting the namespace explicitly. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: I really hate .NET especially inside Delphi
    ... The question answers itself - you can't preserve the implicit make logic ... would the move to explicit make logic bring any ... explicit make system of a language (like Chrome, ... So when I write a class that extends a class in some other namespace, ...
    (borland.public.delphi.non-technical)