[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
|