The Trunk: Collections-topa.565.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Collections-topa.565.mcz

commits-2
Tobias Pape uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-topa.565.mcz

==================== Summary ====================

Name: Collections-topa.565
Author: topa
Time: 25 March 2014, 2:28:36.459 pm
UUID: b7c264b3-1e69-494d-8979-6f71bc9b846d
Ancestors: Collections-ul.564

When a stream is created on a collection, it tries to keep
using that collection instead of copying, even in the case
of mutation of the original collection.

The code removed prevented this.

=============== Diff against Collections-ul.564 ===============

Item was changed:
  ----- Method: WriteStream>>nextPut: (in category 'accessing') -----
  nextPut: anObject
  "Primitive. Insert the argument at the next position in the Stream
  represented by the receiver. Fail if the collection of this stream is not an
  Array or a String. Fail if the stream is positioned at its end, or if the
  position is out of bounds in the collection. Fail if the argument is not
  of the right type for the collection. Optional. See Object documentation
  whatIsAPrimitive."
 
  <primitive: 66>
- ((collection class == ByteString) and: [
- anObject isCharacter and:[anObject isOctetCharacter not]]) ifTrue: [
- collection := (WideString from: collection).
- ^self nextPut: anObject.
- ].
  position >= writeLimit
  ifTrue: [^ self pastEndPut: anObject]
  ifFalse:
  [position := position + 1.
  ^collection at: position put: anObject]!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-topa.565.mcz

Nicolas Cellier
OK, I see this works anyway because ByteString>>at:put: will handle the case and use becomeForward:

But should we rely on this expectation? It comes from a Smalltalk where become: were cheap.
For example, WriteStream>>pastEndPut: does not preserve collection identity


2014-03-25 14:28 GMT+01:00 <[hidden email]>:
Tobias Pape uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-topa.565.mcz

==================== Summary ====================

Name: Collections-topa.565
Author: topa
Time: 25 March 2014, 2:28:36.459 pm
UUID: b7c264b3-1e69-494d-8979-6f71bc9b846d
Ancestors: Collections-ul.564

When a stream is created on a collection, it tries to keep
using that collection instead of copying, even in the case
of mutation of the original collection.

The code removed prevented this.

=============== Diff against Collections-ul.564 ===============

Item was changed:
  ----- Method: WriteStream>>nextPut: (in category 'accessing') -----
  nextPut: anObject
        "Primitive. Insert the argument at the next position in the Stream
        represented by the receiver. Fail if the collection of this stream is not an
        Array or a String. Fail if the stream is positioned at its end, or if the
        position is out of bounds in the collection. Fail if the argument is not
        of the right type for the collection. Optional. See Object documentation
        whatIsAPrimitive."

        <primitive: 66>
-       ((collection class == ByteString) and: [
-               anObject isCharacter and:[anObject isOctetCharacter not]]) ifTrue: [
-                       collection := (WideString from: collection).
-                       ^self nextPut: anObject.
-       ].
        position >= writeLimit
                ifTrue: [^ self pastEndPut: anObject]
                ifFalse:
                        [position := position + 1.
                        ^collection at: position put: anObject]!





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-topa.565.mcz

Tobias Pape
On 25.03.2014, at 21:07, Nicolas Cellier <[hidden email]> wrote:

> OK, I see this works anyway because ByteString>>at:put: will handle the case and use becomeForward:
>
> But should we rely on this expectation? It comes from a Smalltalk where become: were cheap.
> For example, WriteStream>>pastEndPut: does not preserve collection identity
>

People rely on this :)
I actually only got there because a Seaside test failed that made this expectation.

Speaking about expectations.

When I have an A, and I say

        WriteStream on: A

I actually expect the stream to be “on” A.
Become would be ok with me, because the new thing would
be A still, but the collection replacement that happened
up until now would not qualify any longer to be “on A”.

Regarding #pastEndPut:, yes this is debatable, but sending
#pastEndPut: clearly shows that the caller is aware that
the put thing would end up beyond our beloved A. Which makes
this a mere exceptional behavior (not in general but in regard
to the “on A” expectation). It’s a “here be dragons” situation for
me, so anything™ could happen.

Best
        -Tobias



signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-topa.565.mcz

Nicolas Cellier

2014-03-25 21:41 GMT+01:00 Tobias Pape <[hidden email]>:
On 25.03.2014, at 21:07, Nicolas Cellier <[hidden email]> wrote:

> OK, I see this works anyway because ByteString>>at:put: will handle the case and use becomeForward:
>
> But should we rely on this expectation? It comes from a Smalltalk where become: were cheap.
> For example, WriteStream>>pastEndPut: does not preserve collection identity
>

People rely on this :)
I actually only got there because a Seaside test failed that made this expectation.

Speaking about expectations.

When I have an A, and I say

        WriteStream on: A

I actually expect the stream to be “on” A.
Become would be ok with me, because the new thing would
be A still, but the collection replacement that happened
up until now would not qualify any longer to be “on A”.

Regarding #pastEndPut:, yes this is debatable, but sending
#pastEndPut: clearly shows that the caller is aware that
the put thing would end up beyond our beloved A. Which makes
this a mere exceptional behavior (not in general but in regard
to the “on A” expectation). It’s a “here be dragons” situation for
me, so anything™ could happen.

Best
        -Tobias



Bah, Spur become might become cheaper soon anyway... So expectating preservation of identity after the most insane mutations might feel less silly next year (as long as you don't come from haskell or another functional language).
VW Xtreams implementation did rely on it, even in case of growth...