Clashing semantics for #asCollection between Stream parser(S) and MaClientServer

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

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

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; [hidden email]; http://www.rowledge.org/tim
> Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it

> 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; [hidden email]; http://www.rowledge.org/tim
>       > Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it
>
>
>