[squeak-dev] The Inbox: Collections-cmm.836.mcz

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Jun 5 21:41:35 UTC 2019


Le mer. 5 juin 2019 à 22:50, Chris Muller <asqueaker at gmail.com> a écrit :

> >> > I don't much like WriteStream on: String empty.
> >> > If String empty is implemented as answering a literal, and WritStream
> implemented to become the grown contents as it originally did in st80 and
> could also do in Squeak now that we have a fast become, we take the risk to
> modify the literal...
> >>
> >> We both know that's not going to happen.  #empty has been a class-side
> >> constructor/accessor on several classes for a long time, with > 100
> >> senders in trunk alone.  It's an integrated part of the
> >> class-library's API which improves performance and readability.  Any
> >> attempt to switch back to a become implementation for growing internal
> >> collections would spoil that API everywhere.
> >>
> > The number of senders does not matter.
> > What is important is that it's programmer responsibility to make sure
> that this strings won't be mutated (become'd).
> >
> > Until we protect our literals...
>
> Fair enough.  I respect your argument.
>
> >> > String new better express our intention, we want a new substring.
> >>
> >> But sometimes we trade intention-revealingness for performance.
> >> That's what this is.
> >>
> >> I would offer the compromise of WriteStream on: '',
> >> but with #empty
> >> being an integrated part of the API, it's the intent as everywhere
> >> else it's used.
> >>
> >>
> > I would be very surprised if you could measure any difference between
> String new and String empty in this specific case.
>
> Yes, especially since we're talking about making a collection of
> subStrings: anyway...   :)
>
> I'm convinced.
>
> >> > Also, contents does not necessarily answer a copy,
> >>
> >> But it does.  WriteStream>>#contents answers a #copyFrom:to: and even
> >> the comment says "Answer with a copy ..."
> >>
> >>  - Chris
> >>
> > It does not necessarily.
> > For example in Xtreams, you'll see this method:
> >
> > XTSequenceableCollection>>close
> >      position < destination size ifTrue: [destination := destination
> copyFrom: 1 to: (position min: length)]
> >
> > The copy is omitted if unnecessary.
>
> How does XTSequenceableCollection>>#close from an external package
> relate to use of a temporary WriteStream inside the method,
> String>>#subStrings:?
>

If instead of explicitly allocating new substring target, we decide to
reuse a recipient for optimization purpose, we then depend on
implementation details, like assuming that contents does always copy.

Xtreams illustrates that such details may vary from one stream
implementation to another. As an alternate stream implementation based on
composition rather than inheritance, Xtreams has been seriously considered
as a potential Stream replacement, at least in Pharo, so it's kind of
Stream refactoring that may happen.

If we authorize ourself to omit a copy at one place (substrings) we might
as well do it at a more general place (contents) for same reasons...

We can also take such implementation details as granted and consider that
they are part of the contract. The longer the contracts, the greater the
chance to break the contract when we want to evolve/refactor the features.
That's often the price we pay for optimizing...

I'm ok with those design decisions if it really makes a measurable
difference, but we might better add tests to make the contract explicit.


> > I think that VW version additionally use destination become: (but I do
> not have a copy handy)
> > We can consider that contents always copy as part of the contract.
> > It's a matter of depending on very short contract, or long and detailed
> contract.
> > Classical price of optimization...
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190605/ee4caed9/attachment.html>


More information about the Squeak-dev mailing list