On Thursday, 12 July 2012 at 17:51:32 UTC, Andrei Alexandrescu
wrote:
On 7/12/12 1:40 PM, David Piepgrass wrote:
1. Most importantly, the C++ template approach is a big pain
for
large-scale systems, because in such systems you want to
create DLLs/SOs
and C++ has neither a standard ABI nor a safe way to pass
around
template instantiations between DLLs (in the presence of
changes to
internal implementation details). Similar problems exist for
D, yes?
It's a lot easier to define a standard ABI for classes than to
solve the
cross-DLL template problem.
The thing is, that can be done in an opt-in manner. People who
want methods in the root of the hierarchy can define a root
that defines them. But there's no way to opt out of inheriting
Object. Basically it's nice to not force people to buy into a
constrained environment without necessity.
+1
4. Template bloat is no big deal on desktops but it becomes a
bigger
problem as the target system gets smaller. Maybe some
compromise should
be made to ensure D remains powerful and capable on small
targets.
I think virtuals are an equally, if not worse, problem in
memory-constrained systems. The simple solution people choose
for such - they use them judiciously. Here actually templates
may be at an advantage because of their opt-in quality.
+1. Such seams give flexibility that otherwise would be extremely
hard to achieve.
There were two proposals yesterday that I liked. Taken
together, they
address all the problems that were raised with const functions
in Object:
1. Provide a 'safe workaround' for const, for caching and lazy
evaluation (implement it carefully to avoid breaking the
guarantees of
immutable)
We should explore this option in any case. At this point I'm
starting to believe (a) we're doing the right thing by
marginalizing the four methods aside from this issue, (b)
caching is good for other things than this particular problem.
+2 (Especially if it would be possible to redefine 'lazy', so
that it would evaluate at most once.)
