On Wed, Mar 29, 2017 at 8:02 PM, Alistair Grant <[email protected]> wrote: > 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.
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 <[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) >>> ! ! >
