--- Comment #16 from Denis Derman <denis.s...@gmail.com> 2011-01-24 05:40:24
(In reply to comment #15)
> This wouldn't work because the dynamic type of the object being formatted can
> differ from the static type the template was instantiated with. Even if the
> compile-time check won't detect the overriden toString, we would still need to
> perform the check at run-time. The easiest way is to compare the address of
> passed-in object's toString to that of Object.toString. Unfortunately that
> won't work for objects coming from DLLs since they have distinct
> Object.toString functions. So the correct way is to do proper lookup by name
> via run-time reflection.
We may find a way to tell apart, for classes, builtin from toString from custom
one. If we cannot, then in doubt toString must have precedence for classes.
Note there is another bug: one currently cannot implement a range interface on
a class that defines toString (because formatValue template constraints are not
In any case, struct toString must have precedence.
It is an obvious choice: programmers explicitely define toString (later,
writeTo) precisely for that ;-)
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------