[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 #7 from Denis Derman <denis.spir at gmail.com> 2010-12-15 14:36:42 PST ---
(In reply to comment #6)
> > > 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.

Well, our views are clearly pointing to opposite directions and cannot
compromise.
First, you seem to consider ranges as types, while for me they are aspects of
types, implemented as parts of type interfaces. For me, they just play a role,
possibly among others.
I agree it's nice to have a default (array-like) output form for types that
happen to implement a range interface if, and only if, the programmer does not
specify any custom form. I also agree uniformity may be a nice _option_ in some
particuliar cases; as long as it is chosen by the programmer, not imposed. In
which proportion of cases will the default range format happily fit the
programmer's needs for a type that (also) implements the range interface? Say
you wraps a custom string type in a struct to provide specific functionality,
or a set of filenames and dirnames representing a dir structure, or a symbol
table; will it fit?
The case of ranges is completely different from the one of arrays, precisely. 
First, because array types are types; second because array types can only be
that, there is no "array aspect" of a type that would also be something else;
third, because one cannot specify any output form of an array. For all these
reasons, D's default format for arrays is a great feature (and languages that
do not provide any such feature are painful). But none of these reasons apply
to range interfaces.

I agree the impossiblity to distinguish explicite and inherited toString for
classes is an issue. But for this reason, your choice is to ignore the
programmer's explicite intent in all other cases. I find this totally
inacceptable.
Firstly for debug, as you say, programmers want feedback output to be exactky
the way they state it to be; not in a default form that may by chance express
half of what they need in a form that more or less fits their wishes.

I don't understand you point about "Now if we bundle data and Range interface
together all kind of funny things happen." A type that implement a range always
holds data, usually provides many other features that just range/iteration, and
sometimes provides several ranges: for instance, a tree can hold differents
kind of data fields, expose various operations like inserting a subtree, and
have several ranges to iterates depth-first or breadth-first, or only on
leaves, etc.
Maybe an different point of view would be to find a way for the user to express
"use the range interface for output formatting".

(Now, basta.)

Denis

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