On processors for D ~ decoupling

[Walter Bright]

kris wrote:
> If you'll read the posts again, sans prejudice, I hope you'll find that 
> they are about decoupling (like the title says).

What I did is ask what is being coupled that needs decoupling, i.e. 
trying to drill down to find the *real* issue with printf and 
std.string.toString. I don't agree with the notion that printf and its 
4K of code is in the same category as Java's entire runtime library. In 
other words, I do not agree with absolutes like "coupling is always 
bad." Each case should be looked at individually on its merits.

For printf, the actual coupling problem is:

1) It pulls in floating point formatting code. This turns out to not be 
correct.
2) It's bloated. The bloat turns out to be 4K code - a big problem on an 
8 bit machine to be sure, but not on a 32 bit one.
3) It pulls in the entire C I/O system. This turns out to also not be 
correct. It pulls in a reasonable portion of it.
4) It should be replaceable/hookable. Yes, it is.

On the other hand, the advantages of having a print in Object are:

1) Every object can be relied upon to have some sort of print method.
2) Substituting a toString() is problematic because it usually requires 
extra allocation and hence double buffering - so most I/O systems avoid 
such designs. Also, the print is often used for debugging, and having it 
be forced to use an allocation can upset what one is trying to debug - 
by causing a gc collection cycle, for example.
3) It being synchronized with C's IO means it doesn't screw up when 
mixed with normal IO code.

If printf pulled in a megabyte graphics library, sure, that's 
unreasonable coupling. But it doesn't. So, in my judgment, its benefits 
outweigh its disadvantages. You're free to disagree, but disagreement on 
a judgment call doesn't mean I or you are secretly convinced by the 
other's argument and lying about it.

Let's look at the 'coupling' problem of typeinfo calling 
std.string.toString:

1) It's assumed to link in all of std.string, and everything std.string 
references. This is not correct.
2) std.string does pull in the floating point code, but this is a 
compiler problem and easily (and already in my working version) fixed.
3) There's another problem where it pulled in std.uni, but again, this 
is a compiler problem and easily fixed. So what std.string.toString 
actually pulls in (given the compiler fixes) is just std.string.toString 
and a few bytes of static data.

So, in the end, the coupling turns out to be nonexistent. The assumption 
that calling one routine in a module brings in the entire module is not 
correct (and hasn't been since the late 80's). The proposed solution, 
calling C's itoa(), is problematic because it requires another 
allocation (itoa expects a 0 terminated string). Furthermore, itoa() is 
not a standard C function, so such dependency won't be portable. Writing 
another itoa unique to typeinfo kinda defeats the purpose of writing a 
library with reusable code.


> You made it 
> implicitly clear there was no way you'd consider isolating object.d from 
> std.string in order to make the former more amenable to alternate 
> libraries. Thus, that aspect was completely ignored also.

No, I did not ignore it. I don't feel it's productive to rewrite the 
functions in std.string in each module. std.string is not a burdensome 
piece of code. Should I also rewrite memcpy() in every module? How far 
do you want to go to pursue decoupling for decoupling's sake? And 
suppose Fred discovers a way to double the speed of std.string.toString 
- pursuing your approach would mean none of the rest of the library 
would benefit from that. In my not-so-humble (!) opinion, when you're 
using copy/paste across modules, that's a red flag something is wrong 
with the design.

I'll agree with you that pointless and gratuitous coupling should be 
avoided, but that is not the case with the two examples we're discussing.

> Looking again at your recital of adamant examples, I'm rather sorry, and 
> entirely disappointed that's all you got from this exchange.

I used the word adamant because you haven't acknowledged that I've 
addressed the underlying __fltused and std.uni issues, you haven't 
acknowledged that they are solvable compiler issues rather than library 
design issues, and just keep pushing the same solution.


> Yes, there's certainly truth there; but it apparently makes a point of 
> purging all mention of decoupling ~ that's where frugality lies.

I shall reiterate that what I was doing was addressing what the 
underlying issue with coupling was. If those can be successfully 
addressed, then there is no coupling issue.


> You've again omitted a crucial part. The C runtime itself apparently has 
> all kinds of interdependencies (the console startup/exit code is a prime 
> example).

I did not omit it. I addressed that in my last post.

> Thus, the lists you show are simply the tip of the iceberg. I 
> imagine you already know this quite intimately, so will suggest you do a 
> step-by-step examination of the .map file for Derek's example:
> 
> void main() {}
> and ask yourself just why and where the kitchen-sink is linked?

And as I've already told you, I've already done that and that there are 
good reasons for the code that is linked in.