Posted by
Sven Van Caekenberghe-2 on
Mar 10, 2015; 11:35am
URL: https://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-is-false-tp4810690p4810903.html
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 <
[hidden email]> wrote:
>
>
> El mar 10, 2015 8:13 AM, "Sean P. DeNigris" <
[hidden email]> 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!