Smalltalk › Pharo › Pharo Smalltalk Users

Why `aFileReference asString = aFileReference fullName` is false?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

sebastianconcept@gmail.co

Why `aFileReference asString = aFileReference fullName` is false?

A frequent thing to do is to work with files, so their paths.

Take the image directory for example:

`FileLocator imageDirectory resolve asString`

1) What’s the reason to make `aFileReference asString` to be different to what `aFileReference fullName` answers?

2) What’s the practical use of the current answer of `aFileReference asString`?

Sven Van Caekenberghe-2

Re: Why `aFileReference asString = aFileReference fullName` is false?

The thing before the @ indicates the kind of file system you are on (there are not just disk based files, but virtual in-memory ones, or in-zip ones).

> On 09 Mar 2015, at 16:06, Sebastian Sastre <[hidden email]> wrote:
>
> A frequent thing to do is to work with files, so their paths.
>
> Take the image directory for example:
>
> `FileLocator imageDirectory resolve asString`
>
> 1) What’s the reason to make `aFileReference asString` to be different to what `aFileReference fullName` answers?
>
> 2) What’s the practical use of the current answer of `aFileReference asString`?
>
>

sebastianconcept@gmail.co

Re: Why `aFileReference asString = aFileReference fullName` is false?

right, and what's the practical use of that?

from mobile

> On 09/03/2015, at 12:14, Sven Van Caekenberghe <[hidden email]> wrote:
>
> The thing before the @ indicates the kind of file system you are on (there are not just disk based files, but virtual in-memory ones, or in-zip ones).
>
>> On 09 Mar 2015, at 16:06, Sebastian Sastre <[hidden email]> wrote:
>>
>> A frequent thing to do is to work with files, so their paths.
>>
>> Take the image directory for example:
>>
>> `FileLocator imageDirectory resolve asString`
>>
>> 1) What’s the reason to make `aFileReference asString` to be different to what `aFileReference fullName` answers?
>>
>> 2) What’s the practical use of the current answer of `aFileReference asString`?
>>
>>
>
>

Esteban A. Maringolo

Re: Why `aFileReference asString = aFileReference fullName` is false?

Yo should use #pathString to obtain the full path of the file reference.

#asString isn't implemented in FileReference and it's inherited from
Object, which delegates it to the default implementation of
#printString, which isn't intented to be user friendly, and not for
conversion.

Regards!

Esteban A. Maringolo

2015-03-09 22:35 GMT-03:00 Sebastian Sastre <[hidden email]>:

> right, and what's the practical use of that?
>
> from mobile
>
>> On 09/03/2015, at 12:14, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> The thing before the @ indicates the kind of file system you are on (there are not just disk based files, but virtual in-memory ones, or in-zip ones).
>>
>>> On 09 Mar 2015, at 16:06, Sebastian Sastre <[hidden email]> wrote:
>>>
>>> A frequent thing to do is to work with files, so their paths.
>>>
>>> Take the image directory for example:
>>>
>>> `FileLocator imageDirectory resolve asString`
>>>
>>> 1) What’s the reason to make `aFileReference asString` to be different to what `aFileReference fullName` answers?
>>>
>>> 2) What’s the practical use of the current answer of `aFileReference asString`?
>>>
>>>
>>
>>
>

Ben Coman

Re: Why `aFileReference asString = aFileReference fullName` is false?

On Tue, Mar 10, 2015 at 9:52 AM, Esteban A. Maringolo <[hidden email]> wrote:

Yo should use #pathString to obtain the full path of the file reference.

#asString isn't implemented in FileReference and it's inherited from
Object, which delegates it to the default implementation of
#printString, which isn't intented to be user friendly, and not for
conversion.

Regards!
Esteban A. Maringolo

Thanks for the explanation Esteban. Now the followup question is whether its natural to expect something better from #asString, and other people will fall into the same trap?

cheers -ben

2015-03-09 22:35 GMT-03:00 Sebastian Sastre <[hidden email]>:

> right, and what's the practical use of that?
>
> from mobile
>
>> On 09/03/2015, at 12:14, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> The thing before the @ indicates the kind of file system you are on (there are not just disk based files, but virtual in-memory ones, or in-zip ones).
>>
>>> On 09 Mar 2015, at 16:06, Sebastian Sastre <[hidden email]> wrote:
>>>
>>> A frequent thing to do is to work with files, so their paths.
>>>
>>> Take the image directory for example:
>>>
>>> `FileLocator imageDirectory resolve asString`
>>>
>>> 1) What’s the reason to make `aFileReference asString` to be different to what `aFileReference fullName` answers?
>>>
>>> 2) What’s the practical use of the current answer of `aFileReference asString`?
>>>
>>>
>>
>>
>

Sean P. DeNigris

Re: Why `aFileReference asString = aFileReference fullName` is false?

Administrator

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.

Cheers,
Sean

Tudor Girba-2

Re: Why `aFileReference asString = aFileReference fullName` is false?

Indeed. In GT, we introduced gtDisplayString which is meant to be used as a default brief string representation.

I think that we could promote this to displayString now that it is in the Pharo image.

Cheers,

Doru

On Tue, Mar 10, 2015 at 12:03 PM, Sean P. DeNigris <[hidden email]> wrote:

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.

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-is-false-tp4810690p4810889.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

www.tudorgirba.com

"Every thing has its own flow"

Tudor Girba-2

Re: Why `aFileReference asString = aFileReference fullName` is false?

Well, not now. In Pharo 5 :)

Doru

On Tue, Mar 10, 2015 at 12:18 PM, Tudor Girba <[hidden email]> wrote:

Indeed. In GT, we introduced gtDisplayString which is meant to be used as a default brief string representation.

I think that we could promote this to displayString now that it is in the Pharo image.

Cheers,
Doru

On Tue, Mar 10, 2015 at 12:03 PM, Sean P. DeNigris <[hidden email]> wrote:
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.

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-is-false-tp4810690p4810889.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

--
www.tudorgirba.com

"Every thing has its own flow"

www.tudorgirba.com

"Every thing has its own flow"

Esteban A. Maringolo

Re: Why `aFileReference asString = aFileReference fullName` is false?

In reply to this post by Sean P. DeNigris

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!

Sven Van Caekenberghe-2

Re: Why `aFileReference asString = aFileReference fullName` is false?

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!

Esteban A. Maringolo

Re: Why `aFileReference asString = aFileReference fullName` is false?

2015-03-10 8:43 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
> 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.

That's why I said it is a matter of taste. In the end, not having a
concrete #asString implementation might be a good choice.

Esteban A. Maringolo

sebastianconcept@gmail.co

Re: Why `aFileReference asString = aFileReference fullName` is false?

In reply to this post by Sven Van Caekenberghe-2

On Mar 10, 2015, at 8:43 AM, Sven Van Caekenberghe <[hidden email]> wrote:

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.

The alternative to no one good solution is to find the sensible less worst solution.

Do we have a way to strategise the answer of asString per supported platform in such a way that it will conform the string representation of the path to a file?

I’m still trying to understand the practical use of the current answer instead of strategize the answer per platform

Sven Van Caekenberghe-2

Re: Why `aFileReference asString = aFileReference fullName` is false?

the standard string representation of an abstract platform independent representation of a file should be that: abstract & platform independent (it would be terrible to mask that behind a platform dependent external representation)

furthermore it makes sense that the print string gives an indication of what it actually is/models: hence it is useful to add the type reference (else totally different ones will look the same)

there are other accessors that do what you want, why can't you use those ?

most objects cannot come up with just one single canonical representation

for example, according to universal standards, ZnUrl and ZnMimeType can do this, but these are exceptions

> On 10 Mar 2015, at 16:47, Sebastian Sastre <[hidden email]> wrote:
>
>
>> On Mar 10, 2015, at 8:43 AM, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> 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.
>
> The alternative to no one good solution is to find the sensible less worst solution.
>
> Do we have a way to strategise the answer of asString per supported platform in such a way that it will conform the string representation of the path to a file?
>
> I’m still trying to understand the practical use of the current answer instead of strategize the answer per platform

sebastianconcept@gmail.co

Re: Why `aFileReference asString = aFileReference fullName` is false?

On Mar 10, 2015, at 12:57 PM, Sven Van Caekenberghe <[hidden email]> wrote:

the standard string representation of an abstract platform independent representation of a file should be that: abstract & platform independent (it would be terrible to mask that behind a platform dependent external representation)

furthermore it makes sense that the print string gives an indication of what it actually is/models: hence it is useful to add the type reference (else totally different ones will look the same)

there are other accessors that do what you want, why can't you use those ?

most objects cannot come up with just one single canonical representation

for example, according to universal standards, ZnUrl and ZnMimeType can do this, but these are exceptions

I’m already using alternatives to asString, I’m not stuck, I’m trying to understand why asString is not providing what I consider a practical answer to a universal need (string representation of a file reference).

Why the strategy of asString would not have a fallback to a really abstract representation for an unknown platform and return the useful answer for when is familiarized to a particular OS?

Aren't *nix platforms universal enough?

Peter Uhnak

Re: Why `aFileReference asString = aFileReference fullName` is false?

In reply to this post by Sven Van Caekenberghe-2

/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.

file:// is URI scheme and as per RFC ( http://tools.ietf.org/html/rfc1630 ) there is always forward slash; even on Windows.

After all as we've found with git, using backslashes on Windows doesn't even work... so maybe use file:// as universal scheme?

Sven Van Caekenberghe-2

Re: Why `aFileReference asString = aFileReference fullName` is false?

> On 10 Mar 2015, at 17:31, Peter Uhnák <[hidden email]> wrote:
>
> /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.
>
> file:// is URI scheme and as per RFC ( http://tools.ietf.org/html/rfc1630 ) there is always forward slash; even on Windows.
> After all as we've found with git, using backslashes on Windows doesn't even work... so maybe use file:// as universal scheme?

I don't agree, because *IT IS NOT A FILE URL*, *IT IS MORE*

It is a thing that looks like an abstract file of something that looks like a file system, not necessarily a regular disk based one, this has to be reflected in its general print representation, else you are lying/confusing the user

stepharo

Re: Why `aFileReference asString = aFileReference fullName` is false?

In reply to this post by Tudor Girba-2

Please open a bug entry that we do not forget and yes we need displayString

Well, not now. In Pharo 5 :)

Doru

On Tue, Mar 10, 2015 at 12:18 PM, Tudor Girba <[hidden email]> wrote:

Indeed. In GT, we introduced gtDisplayString which is meant to be used as a default brief string representation.

I think that we could promote this to displayString now that it is in the Pharo image.

Cheers,

Doru

On Tue, Mar 10, 2015 at 12:03 PM, Sean P. DeNigris <[hidden email]> wrote:

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? '<a class="moz-txt-link-freetext" href="file://">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.

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-is-false-tp4810690p4810889.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

--

www.tudorgirba.com

"Every thing has its own flow"

--

www.tudorgirba.com

"Every thing has its own flow"