On 29 March 2017 at 13:33, Esteban Lorenzano <[email protected]> wrote:
>
> problem is this part: '../e’
> it has to be any of this:
>
> ('/a/b/c/d' asFileReference / '..' / 'e') path. "Path / 'a' / 'b' / 'c' / 'd'
> / '..' / 'e'"
> ('/a/b/c/d' asFileReference parent / 'e') path. "Path / 'a' / 'b' / 'c' / 'e'"
>
> the rationale is that “..” is not modelled as a special kind of node, just a
> string.
> and the reason is that that’s commonly like that, but it doesn’t *has
> to* be like that… there could be file systems that interprets .. as a
> simple string.
Except that ".." is treated as a special case at the moment in
Path class>>addParentElementTo:, which is why #resolve: does the right
thing (well, at least in my opinion :-)).
While I agree that a more general solution is mostly a better solution,
I'm not aware of any file system at the moment that doesn't treat .. as
the parent directory, and Pharo already treats .. as a special case.
I'm having trouble understanding the Path class comments, however:
"#* and #/ are mnemonic to . and /
whose arguments should be string file- or directory names, not
fragments of Unix path notation intended to be parsed."
seems to imply that segments should not contain the delimiter (/), and
the current implementation leaves the delimiter in the segment.
> and everything can be improved :)
I still think this would be an improvement. :-)
> Esteban
Thanks!
Alistair
>> On 29 Mar 2017, at 12:21, Alistair Grant <[email protected]> wrote:
>>
>> Hi All,
>>
>> The current implementation of Path>>/, while functional, seems to me to
>> create poorly formed paths, e.g.:
>>
>> ('/a/b/c/d' asFileReference / '../e') path ==> "Path / 'a' / 'b' / 'c'
>> / 'd' / '../e'"
>>
>> As can be seen above, the last segment is '../e'.
>>
>> I would expect the result to be:
>>
>> "Path / 'a' / 'b' / 'c' / 'e'"
>>
>> Is there a reason for the current behaviour? If not, are people open to
>> modifying Path>>/ to produce the suggested result above (in Pharo 7)?
>>
>> The method below produces the modified result above and doesn't change
>> the result of running all automated tests. If this is going to be added
>> to Pharo 7 I'll create an additional automated test to check that it is
>> working properly.
>>
>> Cheers,
>> Alistair
>>
>> 'From Pharo6.0 of 13 May 2016 [Latest update: #60451] on 29 March 2017
>> at 9:40:41.681228 am'!
>>
>> !Path methodsFor: 'navigating' stamp: 'AlistairGrant 3/29/2017 09:39'!
>> / aString
>> | path |
>>
>> aString isEmptyOrNil
>> ifTrue: [ Error signal: 'Path element cannot be empty or nil'].
>>
>> ^self resolve: (Path from: aString)
>> ! !
