Hi Sven, On Mon, Apr 03, 2017 at 06:06:57PM +0200, Sven Van Caekenberghe wrote: > That might be OK, I guess, but you have to add enough unit tests to > cover all edge cases.
I'll certainly have unit tests in place when I submit the proposed changes. (the current unit tests have the same results after applying the code below). Which edge cases are you thinking of? Thanks! Alistair > 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 > > > >
