[Pharo-project] WriteStream, nextPutAll:, OrderedCollections

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Jun 14 07:18:46 EDT 2012


Here is a bit less dumb evaluation of stream protocols,  top 100
Stream-messages sent in Pharo2.0 but by Stream:

selectors := (Stream withAllSubclasses inject: Set new into:
[:allSelectors :aClass | allSelectors addAll: aClass selectors;
yourself]) sorted.

references := selectors collect: [:e | e -> ((SystemNavigation default
allCallsOn: e)
	reject: [:aRef | (Smalltalk at: (aRef classSymbol readStream upTo:
Character space) asSymbol) inheritsFrom: Stream]) size ].

(references sorted: [:a :b | a value > b value ]) first: 100.

{#=->7340. #size->3817. #do:->2612. #name->1366. #isEmpty->1345.
#nextPutAll:->991. #nextPut:->887. #value:->792. #contents->741.
#last->679. #cr->666. #initialize->634. #on:->558. #with:->547.
#readStream->497. #position->314. #close->275. #white->266.
#space->256. #next->245. #black->244. #printOn:->226. #print:->215.
#position:->184. #string->175. #lf->171. #atEnd->165. #hash->161.
#reset->156. #tab->130. #text->123. #'<<'->120. #open->112.
#match:->106. #show:->97. #crlf->93. #binary->91. #confirm:->84.
#timeStamp->83. #next:->80. #element->74. #fullName->68. #upToEnd->66.
#removeAll->65. #peek->64. #flush->64. #skip:->63. #findFirst:->61.
#postCopy->55. #replace:with:->52. #nextChunkPut:->52.
#braceArray->52. #isDirectory->49. #fork->49. #url->46. #upTo:->41.
#isBinary->40. #nextLine->39. #header->38. #sendCommand:->34.
#release->33. #request:->32. #nextChunk->30. #uri->29. #store:->29.
#directory->28. #peekFor:->26. #setToEnd->24. #crtab:->24.
#trailer->23. #nextChunkText->23. #skipSeparators->21. #asUrl->20.
#initialize:->19. #upToAll:->18. #textStyle->18. #unregister->16.
#readOnlyCopy->16. #localName->16. #register->15. #nextOrNil->15.
#fileIn->15. #objectAt:->14. #crtab->14. #contentsOfEntireFile->14.
#clear->14. #on:limit:->13. #nextChar->13. #findString:->13.
#write:->12. #skipTo:->12. #converter->12. #string:->11.
#nextWord->11. #next:putAll:startingAt:->11. #initializeOn:->11.
#endEntry->11. #converter:->11. #basicNextPut:->11. #basicNext->11}

- Some should be removed due to false polymorphism
- Some should be isolated because specific (TranscriptStream,
Generator, Transcripter ...)
- Some should be removed thanks to a rewrite of bloated converters (basic*)
But this give an idea of main protocol usage in image.
As for 3rd party packages, this is another story... But Pharo is in a
better position than Squeak for such hard decisions.

Nicolas

2012/6/14 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> I would address the problem with a compatibility layer like
>     'foo' reading withLegacyProtocol
> You have many options to add a protocol
> - simply add the protocol at XTReadStream/XTWriteSTream roots
> - just create another Xtreams wrapper,
> - use a Trait
>
> I wish I had lightweight traits, I mean with traitified classes
> created on the fly, with a simple naming like XTCollectionReadStream +
> TLegacyStreamProtocol in case we have to debug it, because this way I
> could also keep a clean Xtreams hierarchy in parallel with legacy at
> very low maintenance costs.
>
> However, this is going to be some work for sure, here is a rough measurement:
>
> (Stream withAllSubclasses inject: Set new into: [:allSelectors :aClass
> | allSelectors addAll: aClass selectors; yourself]) sorted size
> -> 594
>
> (XTReadStream withAllSubclasses , XTWriteStream withAllSubclasses
> inject: Set new into: [:allSelectors :aClass | allSelectors addAll:
> aClass selectors; yourself]) sorted size
> -> 119
>
> You certainly don't want to support 594 compatibility messages...
>
> Nicolas
>
> 2012/6/14 Igor Stasenko <siguctua at gmail.com>:
>> On 14 June 2012 08:33, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>>> Tx
>>>
>>> now there is a difference between adjustments and fully new API and I would have preferred adjustments.
>>>
>>> Stef
>>
>> IMO, Xtreams design is simply superior.
>> But i agree, we cannot throw existing streams out.. too much things
>> tied to them, and rely
>> on using stream protocols. :(
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>




More information about the Pharo-dev mailing list