[Issue 5354] formatValue: range templates introduce 3 bugs related to class & struct cases

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5354



--- Comment #6 from Nick Voronin <elfy.nv at gmail.com> 2010-12-15 11:46:24 PST ---
> > 1. Using Range interface for formatting classes and structs is a good thing and
> > should stay.
> 
> Why? Please criticise my arguments above, especially:
> * Formatting a type exactly according to the builtin default format of an array
> has no reason to be a common case. Note that a range interface is only _one
> aspect_ of a type.

It looks for me that foremost property of Range is that it can be iterated and
something can be accessed through it. It makes perfect sense that default
formatting tries exactly this -- iterate and format what can be accessed. Now
if we bundle data and Range interface together all kind of funny things happen.
If we separate data and Range object -- everything makes sense. Data is stored
in container which may or may not define toString, while Range only gives
generic access to underlying data. Of course one may define toString for Range
object, but if you think of a Range this way -- as a separate concept with
limited purpose -- there is no need for it.

In a sense I disagree with the notion of "range interface is only _one
aspect_ of a type." I think Range should be considered foremost aspect of a
type... Well, just my opinion, of course. for me mixing Range interface with
other things is not a good practice.

> * Even in this case, writing a 3-4 line toString is not a big deal.

True. But 3-4 line for every Range? Of course one may just provide template for
currently default formatting of Ranges and let user decide what to use.
Actually I think this is what the issue boils down to: we need proper way to
define custom formatting which would be preferred over library generics if
provided. Something of higher level than toString.

> * Introducing default array-like formatting for ranges also introduces semantic
> and implementation issues & complication of the code base. 

I don't see it. Unability to override default formatting is an issue, yet
default formatting in itself is a good thing.

> No! _Default_ range interface formatting cannot have priority over
> _explicitely_ defined formatting by the programmer. 

I would totally agree with you if there was any way to distinguish overridden
toString for classes from original one. I don't know one, so I place priority
on uniformity, simplicity and predictability. Structs and classes behaving same
way is a good thing.

> This is a serious conceptual bug.

I would say it just "conceptual". It's not pretty, it may be somewhat limiting
ATM, but it's better than increasing complexity, generating more special cases,
placing a burden on programmers for what should be provided by library
automagically... (*) I mean it's way easier to cope with clearly stated limits
that deal with mess of complex condition and special cases. Alternative would
be cleaner design for whole system of object to string conversion.

(*) Note, default formatting is widely used inside of library for debugging
purposes, it must deal with all sort of objects in uniform way and not place
any requirements on code. When _programmer_ wants to format object he's free to
call toString directly or even use custom method for converting. One or another
way for defaults does not really limit programmer other than how he sees some
debug messages.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------