Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re: [LONG] Possible utf8 implementation #553

Closed
p5pRT opened this issue Sep 20, 1999 · 2 comments
Closed

Re: [LONG] Possible utf8 implementation #553

p5pRT opened this issue Sep 20, 1999 · 2 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 20, 1999

Migrated from rt.perl.org#1403 (status was 'resolved')

Searchable as RT1403$

@p5pRT
Copy link
Author

p5pRT commented Sep 20, 1999

From The RT System itself

I wouldn't call that dwimming. I'd call it being failsoft. I'd call
it preserving as much information as possible. But not dwimming. Most
people don't *mean* to get \x{deadbeef} in their error messages.

It's only dwimming if you count that people mean for their programs not
to blow up at odd times, and would usually rather get the information
out in a weird form than in no form at all.

: Most other usages of I/O are for consumption by other
: agents. And I know no other agents (except possibly some non-DOSISH
: filesystems) which will happily survive \x-mutiliated data.

Oh, come now, that's absurd. Most of them will survive just fine,
especially if they think they're reading HTML. Or log files. Or
email. Or almost any kind of flexibly formatted text. Which
admittedly doesn't encompass DOS filenames. Darn.

It's easy to fall into the habit of choosing rigor over vigor.
Certainly, rigor is a necessary evil in some situations. For those
situations we provide "use strict". But that's not the default in
Perl. We already have lots of computer languages with rigor, but not
so many with vigor.

But the Perl default must be to preserve information, to be failsoft,
and to try to make the best of a bad situation. If this makes other
computer programs look bad, well that's their problem. :-)

Larry

@p5pRT p5pRT closed this as completed Apr 22, 2003
@p5pRT
Copy link
Author

p5pRT commented Apr 22, 2003

@iabyn - Status changed from 'stalled' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant