Sorry, but the mechanism is one thing, the semantics another. Calling it displayString won't solve the problem.
The problem is that there is often more than one useful string representation. Like for the example at hand. (FileLocator desktop / 'foo.txt') resolve. Has the following #printString File @ /Users/sven/Desktop/foo.txt OK, both of the following make sense /Users/sven/Desktop/foo.txt file:///Users/sven/Desktop/foo.txt But what about native (OS platform) conventions ? I don't want to see Windows backslashes, but Windows user might disagree. There is not one good solution, hence you must use specific accessors/convertors. > On 10 Mar 2015, at 12:20, Esteban A. Maringolo <emaring...@gmail.com> wrote: > > > El mar 10, 2015 8:13 AM, "Sean P. DeNigris" <s...@clipperadams.com> escribió: > > > > Ben Coman wrote > > > Now the followup question is whether its natural to expect something > > > better from #asString > > > > I feel like #asString is such a general question that no answer would be > > satisfying. What string representation should be returned? 'file://'? > > '/path/to'? And what to do with memory file systems? It's been mentioned a > > few times on the list that we should all be more disciplined in sending e.g. > > #displayString vs. #printString instead of #asString. The more I hear that > > argument, the more sense it makes to me. > > I would remove #asString and use #displayString everywhere. But it should be > implemented in Object, based on a #displayOn: method just like printString > does. > > If a method starts with #as... I read "I will cast this object into something > else". Which will be subject to taste. > > Regarding this particular case I would implement #asString as a delegation to > the method that returns '/foo/bar/baz'. An URL's #asString would return > 'file:///foo/bar/baz'. > > Regards!
