On Friday 26 March 2004 3:44 pm, Scott Wallace wrote:
> I think that it is only those methods that have *multiline string
> literals* within them that are adversely affected in a *substantive*
> way.  There turn out to have been six such methods among the q01-q19
> updates.

My feeling has been that we should consider stripping/converting linefeeds on 
input. Of course, if not done intelligently, this would affect any string 
literals containg CR or LF.

However, since it's exactly these that are likely to be damaged in transit, 
perhaps the best strategy would be to either:

* convert all line-endings and disallow string literals in source that contain 
embedded LF characters, or

* use a modified Scanner to diagnose and fix such situations. I actually wrote 
this, but then figured out that even if we "did the right thing" by retaining 
LF characters in string literals, there would be a strong chance that these 
would not be intentional.

What's the feeling out there? Is it necessary to support arbitrary binary 
string literals in source code that's being compiled from .st code or change 
sets?

Note that the SmartRefStream/ReferenceStream are not what I'm talking about 
here.

Would anyone feel that not being able to safely encode LF characters in source 
string literals would be so painful that converting linefeeds when doing a 
file-in or accepting method source from editors would *not* be a good idea?

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE