http://d.puremagic.com/issues/show_bug.cgi?id=5354
--- Comment #6 from Nick Voronin <elfy...@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: -------