Re: Gotchya with sigslot library

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 04 September 2003 2:09 am, Andrew Tetlaw wrote:
> Hello all,

Hi Andrew,

> I'm using the sigslots library separately in a project

We should have a new release of this library out SRTL. Let me know if 
you want a pre-release build (basically only missing docs in Spanish) 
and I'll post one to the list.

>  and I came
> across this gotchya. Now, this is probably going to seem like
> common sense to you guys, but I'm just a beginner with sigslots so
> bear with me.
>
> I've discovered you cannot connect to a slot that is a function
> defined as a prototype function of the slot object if more than one
> of that type of object exists.

Actually, you can, but the behavior is _very_ counter-intuitive. 
Consider that the first time you connect to that function, it (the 
prototype object's function) is rewritten and subsequent connects (or 
emits) will work on the prototype object property, regardless of the 
specified instance object namespace. This leads to all kinds of funky 
behaviors when class instances assume exclusivity, as is usually the 
case when connecting signals and slots. You almost have to know too 
much about the language to see this one comming, and I'm sorry that 
it bit you. I'll fix the docs tomorrow.

> This is because, as a prototype function the FP is identical for
> all objects of that type and the emitWithArgs function will apply
> the first connArr[fp] it finds which may or may not be the correct
> slot object.

Yep. Sorry 'bout that. I guess that should get a pretty prominant note 
in the docs.

> Phew! Took a day to find that one.

= \

Sorry 'bout that. I'm having to be pretty judicious about this 
internally in NW. I guess I should have made more noise about it 
publicly.

> Example:
> ===============
> I have 2 tabRow objects each with 3 tab objects. A tab object has a
> 'click' signal connected to its parent row's 'activateTab' slot.
> 'activateTab' is defined as a prototype function of the tabRow
> class.
>
> Problem is: When row #2's tabs are clicked row #1 get's the signal.
> This is because row #1 is instantiated first and thus it gets added
> to connArr first. Then when the tab does an emitWithArgs, if finds
> row #1's fp and finds that it matches every time.
>
> So if defined like this there are problems:
>
> tabRow.prototype.activateTab = function() {}
>
> But change it to this and it works fine:
>
> function tabRow() {
>         ...
>         this.activateTab = function() {}
> }

Yep. This is the instance-property vs. prototype object property 
thing. The 2nd way will make sigslot act as you think but will be 
heavier-weight. Unless you're creating hundreds (thousands?) of these 
objects and/or the function is quite large, the overhead won't be 
noticeable in most browser-based situations. It isn't in netWindows.

> ===============
>
> As I said it's probably common sense to you guys, but might be a
> common gotchya for punters like me. the class.prototype method of
> making object.methods is quite common (useful for inheritance).

Well, it's not really any more useful for inheritance than, say, an 
instance property method assigned by the constructor, since you can 
always create an object of the parent class in the child classes 
constructor method (more-or-less a mixin). It is, however, much more 
lightweight (saves at least one Function object per class instance, 
and more in inheritance).

Regards.

- -- 
Alex Russell
[email protected]   BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/Vv1LmIQ6Fa/JYbcRAhFMAKDJJOGNQvKkN13Rea4EbBFNISIPSQCfbQZQ
K4MLXqMNQPDeKCSSSrSSo+w=
=ISXS
-----END PGP SIGNATURE-----


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org