At 11:25 AM 8/4/00 +0200, Johan Vromans wrote:
>[Quoting Hildo Biersma, on August 4 2000, 08:40, in "Re: try/catch (Was: "]
> > Yes, but... this is largely casued by the fact that Java requires you to
> > declare any uncaught parameters on your method specification, and this
> > tends to have a na
On Fri, Aug 04, 2000 at 09:10:38AM +0200, Johan Vromans wrote:
> You missed the point.
>
> If you need 6+ lines of code for each elementary error check, this is
> what is going to happen . . .
You're correct, but that's not what I was suggesting. The magic words are
`for each elementary error c
>> Why would we ever remove a syscall!?!?
>I vote for migration to a module.
And sysopen and fcntl and waitpid and ioctl
Tom Christiansen writes:
> >Maybe we should address this? If we're keeping syscalls just because a
> >possible replacement module is just written wrong, we should fix this.
>
> Why would we ever remove a syscall!?!?
I vote for migration to a module. If you're going to use the
long-winded form o
>Tom Christiansen wrote:
>>
>> >> Thats just because IO::Socket is done wrong
>>
>> >Maybe we should address this? If we're keeping syscalls just because a
>> >possible replacement module is just written wrong, we should fix this.
>>
>> Why would we ever remove a syscall!?!?
>Sorry, wrong verb
Tom Christiansen wrote:
>
> >> Thats just because IO::Socket is done wrong
>
> >Maybe we should address this? If we're keeping syscalls just because a
> >possible replacement module is just written wrong, we should fix this.
>
> Why would we ever remove a syscall!?!?
Sorry, wrong verbage. I me
>> Thats just because IO::Socket is done wrong
>Maybe we should address this? If we're keeping syscalls just because a
>possible replacement module is just written wrong, we should fix this.
Why would we ever remove a syscall!?!?
--tom
> Thats just because IO::Socket is done wrong
Maybe we should address this? If we're keeping syscalls just because a
possible replacement module is just written wrong, we should fix this.
I don't like giving up low-level control either, but imagine something
like this:
$port = shift || 2345
On Fri, Aug 04, 2000 at 05:09:13AM -0600, Tom Christiansen wrote:
> This is my argument against obsolescing the general-purpose socket() et al.
> syscalls in deference to the IO::Socket stuff:
Absolutly. A high level API is ok for those who want it. But you should
never take away the low-level s
>> If you do it the C++ way, you can say:
>> try {
>> first_sub_that_throws_exceptions();
>> second_sub_that_throws_exceptions();
>> } catch {
>> it went wrong
>> }
>How does 'it went wrong' know _which_ of the subs went wrong?
This is my argument against obsolescing
On Fri, Aug 04, 2000 at 11:25:49AM +0200, Johan Vromans wrote:
> How does 'it went wrong' know _which_ of the subs went wrong? For
> example:
>
> try {
> open(file1);
> open(file2);
> open(file3);
> } catch {
> error("could not open one of the file(s)");
> }
>
> which is no
[Quoting Hildo Biersma, on August 4 2000, 08:40, in "Re: try/catch (Was: "]
> Yes, but... this is largely casued by the fact that Java requires you to
> declare any uncaught parameters on your method specification, and this
> tends to have a nasty oil-slick effect.
>
> If you do it the C++ way, y
Johan Vromans wrote:
> You missed the point.
>
> If you need 6+ lines of code for each elementary error check, this is
> what is going to happen (and it _does_ happen in almost every Java
> program I've seen):
>
> try {
>open file
>while read a record
> process its
Steve Simmons <[EMAIL PROTECTED]> writes:
> On Thu, Aug 03, 2000 at 08:54:35PM +0200, Johan Vromans wrote:
> >try {
> > java
> >}
> >catch (Exception e) {
> > think again
> >}
>
> I like this. It's perlish in that it builds off of a well-defined and
> proven mechanis
> In fact, you may as well go the whole way and say that all IO is done via
> optimised IO objects (ie include sockets etc). IO::File and friends
> without the overhead. All of the current open functions simply pass these
> objects around.
I'll stick this in there, definitely. This is just what I
> Are you saying they don't look Perlish now?
>
> And no, all you guys, I'm not trying to shoot down a monadic,
> object-returning open. Please don't assume that.
As funny as it sounds, yes. Mind you, they're not really too weird. But
compared to how most other functions have turned out working
On Thu, 3 Aug 2000, Nathan Wiger wrote:
> > sysopen() should probably be included in the list as well.
>
> Good point.
>
In fact, you may as well go the whole way and say that all IO is done via
optimised IO objects (ie include sockets etc). IO::File and friends
without the overhead. All of th
> sysopen() should probably be included in the list as well.
Good point.
-Nate
On Thu, Aug 03, 2000 at 08:54:35PM +0200, Johan Vromans wrote:
> Peter Scott <[EMAIL PROTECTED]> writes:
> > If we get a good-looking exception throwing/catching mechanism and
> > syntax, this may not matter.
>try {
> java
>}
>catch (Exception e) {
> think again
>}
I
>If we were to agree to make the basic syntax of open() something like:
> $object = open [$filename], [$class];
>There's a lot of cool stuff we could do. In the simplest "mostly looks
>like Perl5" cases, open() can work like shown above. In fact, I'd be
>plenty happy with just this, since it m
Peter Scott <[EMAIL PROTECTED]> writes:
> At 09:01 AM 8/3/00 -0600, Tom Christiansen wrote:
> >Syscalls should use errno. Others may vary.
>
> If we get a good-looking exception throwing/catching mechanism and
> syntax, this may not matter.
try {
java
}
catch (Exception e) {
Bart Lateur <[EMAIL PROTECTED]> writes:
> >The open() and opendir() functions would have to be altered to take one
> >argument (not two) and return the corresponding file object or undef.
>
> Actually, open() currently CAN have just one parameter.
Does that matter much? After all, we may chang
On Thu, 3 Aug 2000, Nathan Wiger wrote:
> Tom Christiansen wrote:
> >
> > >On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote:
> > >> >Modify open() and opendir() to return filehandle objects
> > >>
> > >> Here are some things that that will be a problem for:
> >
> > >I did not se
On Thu, 3 Aug 2000, Graham Barr wrote:
> On Thu, Aug 03, 2000 at 09:01:44AM -0600, Tom Christiansen wrote:
> > >On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote:
> > >> No, that's gross. A failed constructor should return undef. See my
> > >> later message.
> >
> > >That has a
Tom Christiansen wrote:
>
> >On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote:
> >> >Modify open() and opendir() to return filehandle objects
> >>
> >> Here are some things that that will be a problem for:
>
> >I did not see any that would be a problem.
>
> It's not as convenien
At 09:01 AM 8/3/00 -0600, Tom Christiansen wrote:
> >On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote:
> >> No, that's gross. A failed constructor should return undef. See my
> >> later message.
>
> >That has always been my view. But then people say "but why did it fail"
> >and h
On Thu, Aug 03, 2000 at 03:19:35PM +0100, Graham Barr wrote:
> I am open to suggestions. Of course one may be move the connect
> out of the constructor. But that leaves the constructor
> being nothin more than a bless.
Here's a modification of my previous evil suggestion:
Have a global (existing
On Thu, Aug 03, 2000 at 09:01:44AM -0600, Tom Christiansen wrote:
> >On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote:
> >> No, that's gross. A failed constructor should return undef. See my
> >> later message.
>
> >That has always been my view. But then people say "but why did
>On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote:
>> No, that's gross. A failed constructor should return undef. See my
>> later message.
>That has always been my view. But then people say "but why did it fail"
>and having global variables does not scale well.
Syscalls should
On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote:
> No, that's gross. A failed constructor should return undef. See my
> later message.
That has always been my view. But then people say "but why did it fail"
and having global variables does not scale well.
My comment comes mai
>Are you saying that piped opens returning a "filehandle" object makes
>testing for failure more troublesome? If so, I have an evil proposal
>for you ... Let's make an "error" object (I hate to use that term)
>that's *always* false but has some state we can get at. This thing would
>encapsulate
On Thu, Aug 03, 2000 at 06:57:27AM -0600, Tom Christiansen wrote:
> >On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote:
> >> >Modify open() and opendir() to return filehandle objects
> >>
> >> Here are some things that that will be a problem for:
>
> >I did not see any that would
>On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote:
>> >Modify open() and opendir() to return filehandle objects
>>
>> Here are some things that that will be a problem for:
>I did not see any that would be a problem.
It's not as convenient.
--tom
On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote:
> >Modify open() and opendir() to return filehandle objects
>
> Here are some things that that will be a problem for:
I did not see any that would be a problem.
Graham.
>Modify open() and opendir() to return filehandle objects
Here are some things that that will be a problem for:
open(SESAME, "| output-pipe-command") # set up an output filter
open(SESAME, "input-pipe-command |") # set up an input filter
open SPOOLER, "| cat -v | lpr -h 2>/dev/nul
>Actually, open() currently CAN have just one parameter. What it does, is
>use a filehandle and a scalar variable with the same name, so
>Nope. Get rid of it! (p.s. Has anybody ever actually used this feature,
Yes, of course. That isn't an argument for its persistence, however.
--tom
On Wed, 02 Aug 2000 20:58:51 -0700, Nathan Wiger wrote:
>=head1 IMPLEMENTATION
>
>The open() and opendir() functions would have to be altered to take one
>argument (not two) and return the corresponding file object or undef.
Actually, open() currently CAN have just one parameter. What it does, i
37 matches
Mail list logo
