[Seaside-dev] Seaside-Core-topa.811
Philippe Marschall
philippe.marschall at gmail.com
Sun Apr 6 19:58:01 UTC 2014
On Sun, Apr 6, 2014 at 8:44 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
> Hey,
>
> On 06.04.2014, at 19:13, Philippe Marschall <philippe.marschall at gmail.com> wrote:
>
> Hi
>
> Can you elaborate a bit on the problem?
> Can you supply some tests?
> Will this work on GemStone (comparing classes with #==)?
>
> This is a strange thing no matter how we look at it.
>
> #pathStringUnencoded states
> "allocate with correct size, avoid copy"
>
> However, it is working on strings that potentially contain
> unicode stuff.
So?
> The way this method was written did not cope for
> the underlying stream/stream’s collection to change.
How so? The type of collection should not have an influence on the
semantics of #size and if the kind is changed then #becomeForward: is
used and the collection is replaced in place.
> The test will
> fail in mostly any squeak out there (except trunk [1]).
Why?
> Yet, we can only be sure that
> a) the preallocated size is correct and
This is always the case.
> b) the #pathUnencodedOn: will not change the collection kind
> if all path segments are of the same kind (Byte/Wide in Squeak/Pharo
> or one of the equivalent Unicode classes in GemStone…)
Um no. The type of collection still changes if all the elements are
made of WideString in Squeak/Pharo because the initial allocation will
be done with String new: which gives a ByteString instance which will
later change to a WideString.
> Even if the #== in GemStone would fail[2], the failsafe method I
> added will always work, although potentially create a copy.
>
>
> I find it hard to come up with a dedicated test for that except for what
> already is done in WAUtf8UrlTest>>#testPathStringUnencoded (the one that
> triggered all that for me).
If that failed then that's fine. Which version of Squeak was that 4.4? 4.5?
Cheers
Philippe
More information about the seaside-dev
mailing list