Function overloading concern

[Bruno Medeiros]

Walter Bright wrote:
> "Mike Capp" <mike.capp at gmail.com> wrote in message 
> news:durud0$109b$1 at digitaldaemon.com...
>> In article <dur2g6$29us$1 at digitaldaemon.com>, Walter Bright says...
>>> I've seen that scheme. It strikes me as excessively complicated.
>>> Furthermore, there are no implementations of it, so nobody knows if it is
>>> implementable (see "export"), or if it is actually usable (see 
>>> "namespace").
>> In fairness, the proposal is by Daveed Vandevoorde of EDG, who AFAIK are 
>> the
>> only people on the planet who *have* implemented "export". I don't think 
>> he's
>> chucking this stuff out of the window of some ivory tower.
> 
> I have the greatest admiration and respect for Daveed. But nobody is smart 
> enough to reliably predict how useful such a complex addition will be in 
> practice, or what all the corner cases will be, or how difficult it is to 
> implement on any compiler other than his own, etc., all based on a paper 
> proposal.
> 
> Bottom line: the committee's track record on invention of complex new 
> features is poor when they got standardized with no existing implementation 
> experience (see namespace and export). The committee's record on 
> standardizing functionality that *has* been extensively tried out is 
> reasonably good (see STL).
> 
>> My main concern about the proposal as it currently stands is that I can't 
>> see
>> how build tools like "make" can possibly work with it. The model is no 
>> longer
>> "compile a bunch of separate objects and throw them at the linker". To 
>> compile a
>> source file you need to have compiled all source files it depends on, and 
>> all
>> source files *they* depend on, and so on. I'm increasing worried that the 
>> whole
>> module concept may not be workable in a language that doesn't allow 
>> references
>> to undeclared symbols at compile time.
> 
> I.e., it's a design for something that is complicated and quite unique among 
> programming languages. It will *fundamentally* change the way C++ programs 
> are built, probably in unanticipated ways. There's no implementation 
> experience to see how it will work in a real project.
> 
> The risk is that if it gets standardized without being tried, and then 
> people find out that it is either unworkable, unusable, or has little 
> benefit in the real world, then it cannot be taken out again (like export). 
> 
> 
Responding to both what Walter and Mike said:
Isn't this a design that Java, C#, and even D (to a slighty lesser 
degree) do? To compile a .d source file, the compiler must parse all 
other .d files that the original one references (in the form of 
modules), so isn't it the same? What's the whole new different paradigm?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D