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

[Philippe Marschall]

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?

>>> 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.

> I mean, it wouldn't work after all if you used ByteArray and numbers >256 here.
> The case would be the same.
> [...]
> Both.
> Squeak Trunk is save-ish.

Does that mean Squeak Trunk has the same behavior as Pharo or that I
should be able to work with Squeak Trunk without stuff blowing up in
my face?

Cheers
Philippe