Re: Error handling
Timeouts, shouldn't be reliant on UNIX. (Although I dont think they
should
be in the language eigther. A system is easily developed using threads.
something which I hope to develop when perl6 is ready...)
I don't understand this paragraph.
As it stands, if you want to have a timeout on a peice of
code/function/whatever.. you need to use eval, $SIG{ALRM}and alarm()
Unfortuantely alarm() doesnt work on windows (and probobally any other
non-posix os)...
I just think that if Perl6 means one thing, and it effects only one great
change. TRUE platform independance should be it
Java is the success it is because of it. And lets face it, we're all here
because we like Perl more, so to paraphrase Larry "Use the stuff that rocks,
and not the stuff that sucks"...
Fw: println() ... printbr()
- Original Message -
From: "Peter Bevan" [EMAIL PROTECTED]
To: "raptor" [EMAIL PROTECTED]
Sent: Wednesday, August 09, 2000 11:05 AM
Subject: Re: println() ... printbr()
I actually saw this in the newsgroups and thought it was a neat idea.
What
about
println $textvar;
instead of
print "$textvar\n";
Ever so much easier to read and write, prints the arg and appends \n.
]- I thought 'bout this too, but I think it is not general enought..Why
?
we shall then add this too :
printbr "text";
i.e.
print "textBR";
OR printtd, printtr
print "TDtext/TD";
and many other like this !!!
current way for many prints operators is :
$old = $\;
$\ = "\n";
print ...
print ...
print ...
$ =$old;
OR
{
local $\ = "\n";
print ...
print ...
print ...
}
There shall be easier way in Perl6 for doing this ... I too get really
tired
of these "\n" and BR's at the end
ALSO ...
Although I agree that a println is a top idea (not only for ease of use
but
also for cross-platform line end characters)
the other versions you mention (printbr etc) have (in my opinion) no place
within the Perl language. Perl is not a cgi language perse, simply one in
which its is easy to implement and as such it should not contain web
specific functions. That is the function of modules (such as the excellent
CGI module, which will do those things you mentioned anyway)...
print @array;
must work like this :
foraeach (@array) { print "$_\n"};
foraeach (@array) { print "$_BR"};
not like at the moment :
foraeach (@array) { print $_};
This I totally disagree with. The use of an array in scalar context does
(and I believe should always) return it's length. It is one of Perl's
single
most usful features (in my expirience)...
wildcard includes
Just a thought, but I think it woul be a good idea to include the 'java-esqe' practice of including packages via foo.barr.* or in Perl's case Foo::Bar::* (assume that the module include syntax remains the same)... I can see that in the case of some module directories, where the modules are fairly insular it may not be a great idea. However there are some occations where I think that inclusion of multiple modules would be ideal (such as maybe LWP or Net)... What do you think
Error handling
I started writing this mail by asking:
Does anyone else agree that perl should have support for (but not
forcefully) error handling...
maybe a little like Java's??
I know that sort of thing can be acheived with eval(), but surely
Which is as far as I got, because something new has occured to me...
We all know (and most of us love) the timeless Perl ideoms, such as using
eval to trap die's etc
However, with the birth of the new Perl, I think it is time to bury those
ideoms in the language and
start inventing new ones..
Error handling should be supported by it's own keyword i.e.:
trap {
#CODE
}
release (error) {
# ERROR
}
(just because I didn't want to steal throw and catch)
Timeouts, shouldn't be reliant on UNIX. (Although I dont think they should
be in the language eigther. A system is easily developed using threads.
something which I hope to develop when perl6 is ready...)
The list could go on forever... and although I accept that most of them
should stay as they are, there is a little core that should become part of
the language
What do you all think
