> > $groupWatcher->add(\$groupWatcher);
> >
> > in a script. But if I do this in the debugger, my Linux perl crashes
> > with a segmentation fault.
>
> That's strange. Can you post a stack trace?
Hm, I confess the reference usage was wrong! Anywhere else references, but
these are objects (just certain types of references), of course. My fault.
Nevertheless, it should not cause a segmentation fault.
Honestly spoken, these signals kill the debugger completely, so there is no
stack trace. But it is reproducable on Solaris, too. Here are the
instructions:
- snip --
# perl -MEvent -de 0
Loading DB routines from perl5db.pl version 1.0402
Emacs support available.
Enter h or `h h' for help.
main::(-e:1): 0
DB<1> require Event::group
DB<2> $w=Event->group(parked=>1)
DB<3> $w->add(\$w)
Signal SEGV at /usr/local/perl5.005/lib/5.00503/perl5db.pl line 1133
DB::DB called at -e line 1
Abort
- snip --
> The following should work, shouldn't it?
> $w1->add($w2); # without taking a reference
>
> Should it require a reference to the watcher?
No, surely not. Of course, watchers are objects. Sorry.
> All the attributes are the same. What do you want $w->prio(6) to
> return? The old priority or the new priority? Is it really worth the
> trouble of returning anything?
A feature of Perl I really like is that it works in expressions. An operation
supplies something, a statement supplies something, a block supplies something
and so forth. This is VERY useful to nest statements and write compact
programs. (This was already well implemented in C, but even better in Perl.)
Now, here is a method that replies nothing - in certain circumstances. :-( I
like nesting and conciseness. I suggest to reply the new value. It's no really
new information at this point, of course, so someone may prefer the old one,
but I personally think this would be less intuitive.
Jochen
