Re: I really hate .NET especially inside Delphi

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.

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


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...) ?


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.


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.

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

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.


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


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)


--
Jolyon Smith
.

Relevant Pages

  • Re: Code block literals
    ... > What's implicit to me is that the use of an iterator is never specified. ... But such expansion wouldn't be any more "explicit" than USING the ... *iterator usage* in the two languages. ...
    (comp.lang.python)
  • Re: Code block literals
    ... > implicit invocation of an iterator, ... special operation works as indicated by its syntax. ... would not be "more explicit", ... This has nothing to do with "eschewing code blocks", ...
    (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: 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: ? RE: Default Transfer Syntax in Part-10 files?
    ... I find there is no shortage of "bad ideas" in the DICOM standard, ... I find it surprising that the default transfer syntax isn't mandatory ... > supports, and they are all explicit VR, ergo implicit VR ...
    (comp.protocols.dicom)