on 31/10/01 11:47 PM, Scott Raney at [EMAIL PROTECTED] wrote:
> true compability didn't ever seem to be an issue because HyperCard can't deal
> with binary data anyway (nor can any HC user, at least if they're still using
> HC ;-)
can't deal with binary data directly, no, because it uses zero terminated
strings - but that doesn't stop HC/users manipulating lots of files to be
exchanged with other apps that use CR. I've got a lot of stacks like that.
>> defining a new constant "CR", with the wrong value, is just rubbing salt in
>> the wound. Was this inherited from some other xTalk?
> Yup, SuperCard.
I never liked it :-(
> CRLF is already built in and generates the correct sequence.
Oops - why didn't I check that? Sorry.
> And real programmers don't use "line 1" & return & "line 2", they use
> format("line 1\nline 2"). If they need real returns, they can use
> format("line 1\rline 2"). numToChar(13) also works.
Real programmers!??!
Why call a function at run time to define a constant? Format might be a
sensible option in the case you note above (seems like a sledgehammer to
crack a nut, but you'd be the one to know whether it was more efficient or
not) but if the parts are in variables, I'd certainly rather use 'var1 &
return & var2'. By this argument there'd be no call for tab, LF, CR, or
indeed return. Of course we can use numToChar(13) - my small repertoire of
MC (actually Rev) stacks already contains many cases of assigning
numToChar(13) to variables (and a good few of numToChar(13) & numToChar(10),
come to that - have to change those now). I'm not saying that this is a
problem that stops one from doing anything in MC/Rev, but it's still nice to
have alternatives. That's what I like about the xTalks - having many ways
to skin a cat. To coin a phrase "there's an easier way to do that...."
Ben Rubinstein | Email: [EMAIL PROTECTED]
Cognitive Applications Ltd | Phone: +44 (0)1273-821600
http://www.cogapp.com | Fax : +44 (0)1273-728866
Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
