On Wed, Mar 29, 2017 at 8:02 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
On 29 March 2017 at 13:33, Esteban Lorenzano <estebanlm@gmail.com> 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.
Perhaps Pharo should adopts ".." as *its* platform independent "go-up" token. So the (relatively uncommon) platforms that don't conform will need an adapter. cheers -ben
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 <akgrant0710@gmail.com> 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) ! !