That might be OK, I guess, but you have to add enough unit tests to cover all edge cases.
In the past, the reasoning was, AFAIU, that the right side argument to #/ did not get interpreted. But that indeed gives some inconsistencies. > On 3 Apr 2017, at 14:04, Alistair Grant <[email protected]> wrote: > > Hi All, > > I previously suggested a change to Path>>/ which actually covered two > issues: > > 1. The handling of the parent directory notation, i.e. ".." > 2. The construction of path segments when appending a string. > > As Damien pointed out, the first issue needs a bit more consideration. > > I think the second point is still problematic and can be addressed > separately. In particular: > > ('/a/b/c' asFileReference / 'd/e/f') parent "File @ /a/b/c" > > I would expect the result to be "File @ /a/b/c/d/e" > > The fix is straightforward (although someone may be able to propose a > more elgant solution): > > -- > / aString > | path additionalPath index | > > aString isEmptyOrNil > ifTrue: [ Error signal: 'Path element cannot be empty or nil']. > > additionalPath := Path from: aString. > path := self class new: self size + additionalPath size. > path copyFrom: self. > index := self size + 1. > additionalPath do: [ :each | > path at: index put: each. > index := index + 1. > ]. > ^ path > -- > > 1. Do you agree with the proposed change? > 2. (Assuming you agree): Should we target Pharo 6.0 or 7.0? > On one side, this is clearly a bug, on the other, no one has reported > it to date, so it isn't having a big impact. > > Thanks, > Alistair >
