[Kde-perl] Signals & Slots

[Germain Garand]

Le Vendredi 06 Juin 2003 04:03, Ashley Winters a écrit :
> --- Germain Garand <germain at ebooksfrance.org> wrote:

> In order to 'disambiguate' functions I was going to propose:
>
> sub thingyUnsignedInt : alias( thingy(unsigned int) );
> sub thingyLong : alias( thingy(long) );
> sub operatorLShiftInt : alias( operator << (QDataStream&, int) );
>
> That lead me to the non-Perl-like proposal of optionally allowing the
> overloading of "visible" names of signals/slots (for better or worse).

I see. 
Another possible use could be, if/when anonymous sub become legal slots, to 
give them a name so they can be connected/disconnected without having the 
coderef at hand.

So we can let that possibility open.
I think it is safe to assume that if the content of SLOT( ) matches 
/^\s*[a-zA-Z_]+\s*\(.*\)\s*$/ then it can't be anything else but a named 
slot...

Then again I'm not sure about what needs to be changed in the signal/slot 
handling to make this work

>
> As for the warning which mandates the somewhat loud SIGNAL/SLOT
> syntax...
>
> It turns out that the reserved word warning comes from "use warnings
> qw(reserved)". Given the syntax-warping nature of PerlQt, I wouldn't
> hesitate on mandating "no warnings qw(reserved)" for any modules which
> inherit from a Qt class (and by mandating, I mean courteously switching
> it on for them without asking). :)
>
> So, I'm kinda in favor of sub foo : signal(); over sub foo : SIGNAL();
> with an automatic no warnings qw(reserved) in PerlQt classes.
>

That's a tough choice...
- lower case is elegant, but I think the 'reserved' warning is important, 
especially in PerlQt...

e.g, you write:
	print "Something ". must ." be said\n";

but you forget to declare "must" as an attribute, or it has a typo...
You will have a hard time to spot the error without the warning.

- upper case is loud, but not that much if you consider the NEW, SUPER, 
DESTROY, SIGNAL($), SLOT($) that every module will have anyway.

-ucfirst looks like a good compromise, but then you have three different, 
inconsistent statements for signals and slots. Evil.

So at the end of the day, I'd go for all upper case. 
Better safe than sorry...