[squeak-dev] Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

Levente Uzonyi leves at caesar.elte.hu
Tue Aug 13 11:37:34 UTC 2019


On Mon, 12 Aug 2019, Chris Muller wrote:

> Just for a clarification:
>
>       On Mon, 12 Aug 2019, tim Rowledge wrote:
>
>       > I just loaded the Xtreams and Levente's GoogleWikiCompiler into an image that already had Chris' MaClientServer package.
>       >
>       > Running the GoogleWikiCompiler example failed! Oh noes!
>       >
>       > Turns out that in GoogleWikiCompiler>LinkShort: the use of
>       > address, '.html'
>       > to merger a collection of characters with the string '.html' relies on the implementation semantics of #asCollection to leave a String as a String
> 
> 
> That's a bug in that code.  Brent Pinkney originally implemented #asCollection to be a pointer collection (e.g., not bytes), to support concatenation syntax, as in:
> 
>    myObject1, myObject2, myObject3    "==> { myObject1. myObject2. myObject3 }"
> 
> It was also to allow input arguments of methods which expected collection arguments to also allow single arguments.
> 
> The history is, it was proposed for Squeak, but someone objected, but to at least _allow_ people to load and use it optionally, Collection>>#asCollection and two senders in core code were needed.
> 
> GoogleWikiCompiler should be fixed.

So, in your opinion, should

 	#($a $b $c), 'def'

give

 	#($a $b $c $d $e $f)

or

 	#($a $b $c 'def')

?

(GoogleWikiCompiler/Xtreams-Parsing assumes the former, that's the 
behavior in trunk images, and that's what I would expect as well.)

> 
>
>       - after all, it's a collection of characters, right?
>       >
>       > However, Chris has changed that for MaClientServer such the String is returned as
>       > Array with: theString
>       > which doesn't play nice with the above.
>       >
>       > I'm not entirely sure I like either approach really; #($a $b $c) , 'foo' doesn't seem like such a great thing to do, especially if you can't guarantee what the actual state of the 'address' object is (that's a
>       bigger issue around the parser behaviour) BUT 'foo' asCollection -> #( 'foo') doesn't seem quite nice either. I could sort of appreciate 'foo' asCollection -> #($f $o $o) I suppose.
>       >
>       > The immediate solution within the context of the swiki parsing is to carefully make sure the address is actually a string, so no major issue for me today, but this does indicate a potentially problematic
>       perplexity when mixing xtreams and client server packages.
>
>       If MaClientServer implements String >> #asCollection, then that's a
>       mistake, which breaks #,.
> 
> 
> No it doesn't.  The package also adds Collection>>#, to maintain the proper function, but Tim simply didn't mention that.

YOu mean it overwrites the existing Collection >> #, changing its 
behavior - aka breaking #,.

Levente

> 
> Best,
>   Chris
> 
> 
>  
>
>       I came to the conclusion that without a proper html generator,
>       GoogleWikiCompiler cannot create correct output.
>       I have attached a version of GoogleWikiCompiler (attached), which uses our
>       internal tool: StreamingHtmlCanvas (also attached) to generate html.
>       Yes, that's another dependency, but that's how things go, isn't it? :)
>
>       Also, I had to convert the address variable to a string in links actions.
>       I think you've done the same in your image.
>
>       Levente
>
>       >
>       > tim
>       > --
>       > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>       > Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it
> 
> 
>


More information about the Squeak-dev mailing list