[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