[Seaside] [VW] 2.8a1.390 now available on public store
boris at deepcovelabs.com
Sat Jul 7 15:54:29 UTC 2007
I would suggest adding encodeon to text which would solve the problem when displaystring returns it instead of actual string. But it might not be a bad idea to add safety to object's encodeon to make sure displaystring didn't return self which go into recursion. Nasty, I know.
(Sent from an iPhone... Not!)
----- Original Message -----
From: seaside-bounces at lists.squeakfoundation.org <seaside-bounces at lists.squeakfoundation.org>
To: Seaside - general discussion <seaside at lists.squeakfoundation.org>
Sent: Sat Jul 07 03:29:14 2007
Subject: Re: [Seaside] [VW] 2.8a1.390 now available on public store
2007/7/7, Lukas Renggli <renggli at gmail.com>:
> > Does #displayString in Squeak always return an instance of String? It doesn't here...
> Squeak doesn't have #displayString, we use this just to keep
> portability with VisualWorks. #displayString defaults to #asString in
> Squeak. Isn't this supposed to return a string as its name says?
The reason we went through the whole #displayString pain (implementing
it in Squeak, changing every sender) is because we were told that we
could not use #asString in VW and that #displayString was the method
to use that would always return a String for displaying. Apparently
this is not the case. I'd be interested where this happens. If the
#displayString implementors in VW can't be fixed and are few, I'd
prefer it if we #encodeOn: would be overridden in these cases. Note
that we already have two #asString suckers. WARenderingContext >>
#nextKey and WATagBrush >> #id. I'd be happy if we could get rid of
those by implementing #encodeOn: in Symbol in the VW port.
> Lukas Renggli
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
Seaside mailing list
Seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Seaside