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

[Tobias Pape]

On 07.04.2014, at 17:43, Philippe Marschall <philippe.marschall at gmail.com> wrote:

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

shall I?

> 
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1625 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20140408/f9ae695c/signature-0001.pgp