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 <akgrant0710@gmail.com> 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