[Seaside-dev] Seaside-Core-topa.811

Philippe Marschall philippe.marschall at gmail.com
Mon Apr 7 15:43:39 UTC 2014


On Mon, Apr 7, 2014 at 3:30 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>
> On 07.04.2014, at 12:18, Philippe Marschall <philippe.marschall at gmail.com> wrote:
>
> On Sun, Apr 6, 2014 at 10:17 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
> Hey,
>
> On 06.04.2014, at 21:58, Philippe Marschall <philippe.marschall at gmail.com> wrote:
>
> 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.
>
> If we were operating on a string, directly, yes.
> But can we _Really_ know this for a stream? A stream can do on
> its collection what it wants.
>
>
> The test will
> fail in mostly any squeak out there (except trunk [1]).
>
> Why?
>
>
> Because when using a write stream on a byte string and putting
> a wide character onto it, the write stream would pro-actively
> replace its own underlying collection with a wide one, _NOT_ doing
> a #becomeForward:/#become: at all.
>
> I see. Is that relatively new change in Squeak?
>
> No, it is that way since 2005 at least.
> Actually, I changed it so that now #becomeForward: is used.

I see.

> 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.
>
> But you cannot be sure to get the collection back you put in (see above).
> I also do not think that this is the contract of WriteStream.
>
> I asked a few long-time smalltalkers who said they would not expect the underlying
> collection to stay the same if you put not-directly-compatible things in there.
>
> Right. But then I would expect the fix to fail if all of the path
> elements are WideString. The test would assume that it's safe since
> all elements are of the same class but WriteStream will change the
> collection anyways.
>
> Hmph, yes, correct.
> The inital collection should take the species of the first element of the stream
> then, right?

species or class I'm not sure which one.

Cheers
Philippe


More information about the seaside-dev mailing list