major functional changes to __sig___ (mutators!)

Alex Russell <[email protected]> Wed, 8 Sep 2004 11:15:35 -0700
Newsgroups gmane.comp.windows.devel.netwindows
Organization netWindows.org
Message-ID <[email protected]>
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hey everyone,

=46or people that haven't been following the CVS checkin mailing list, I=20
wanted to keep everyone aprised of some major additions to the=20
capabilities of the __sig__ object as well as some recent changes=20
that may affect what you see when you use it.

=46irst off, exceptions in slots are now squelched (but logged). This IS=20
A BEHAVIOR CHANGE and I expect that it could lead to subtle failures.=20
OTOH, the other choice was to NOT squelch and have subtle cascading=20
failures for slots which are not related and in situations where the=20
failure of one slot should not block the rest of the slots from being=20
called. On the upside, there IS now a toggle for this. See the docs=20
for the new property __sig__.squelchSlotExceptions. This is a=20
_global_ toggle, as there is no per-connection toggle for=20
squelching/passing yet.

And speaking of per-connection options, sigslot now has mutators!!

The documentation is still a little thin on this, so I'll outline here=20
what they are and why you might want them.

It is very often the case that when I'm connecting two=20
methods/functions, I will not want exactly the parameters that are=20
passed to the signal to be passed to a slot. Very often in fact, I'll=20
want some kind of result or permeutation on the original argument.=20
__sig__ now supports two types of mutators to handle this=20
eventuality:
	* per-argument mutators
	* a "final" mutator

per-argument mutators take one argument as a value and must return one=20
value which is used in the place of the original argument. Like=20
default values, per argument mutators are registered at connection=20
time as positional items in an array.

But what about when I want to do something like change the order of a=20
set of arguments? Or drop one (or more) of them? This is where the=20
"final" mutator comes into play. It accepts the entire arguments=20
array (actually converted to an Array before being passed, so all=20
Array methods are available) and it MUST return an Array object which=20
represents the new order of arguments to be passed to the slot. The=20
final mutator is called (if one exists for a connection) after all=20
default, over-ride, and mutator processing has been done on a set of=20
arguments, so what you get into the final mutator is exactly the set=20
of arguments that your function would be called with.

Which reminds me of the new syntax for over-rides. Previously, there=20
was a documented facility for specifying "default" arguments to a=20
slot when the arity of the signal was less than that the slot was=20
expecting (or if it was passed with null). There was also an=20
un-documented flag for doing over-rides for arguments which DID exist=20
in the call to the signal, but that you wanted to replace with=20
something else in your slot's arguments. This has been replaced with=20
a new positional array argument to connect() similar to the one for=20
defaults. Over-rides always "win" out over the arguments for the=20
signal, but may still be munged by either positional or final=20
mutators.

So there's a lot going on, and the number of potential arguments to=20
__sig__.connect() has expanded to something silly. Which means we=20
need a shorter (or at least, more readable) syntax for complex=20
connections...if only we could use "keyword" style arguments to=20
connect()?

Well now you can!

If only one argument is passed to __sig__.connect(), it tries to pipe=20
that argument through the new __sig__.kwConnect(), which takes as=20
it's single argument an object that represents all the things you=20
might want to do to connect. Consider a connection between foo.bar()=20
and baz.xyzzy() which specifies a final mutator that drops the=20
initial argument to foo.bar() when calling baz.xyzzy():

__sig__.connect({
	signalObject: foo,
	signalName: "bar",
	slotObject: baz,
	slotName: "xyzzy",
	finalMutator: function(args){
		args.shift();
		return args;
	}
});

Now, when foo.bar() is called with:

	foo.bar(a, b, c);

baz.xyzzy() will get called with:

	baz.xyzzy(b, c);

I'm making a new sigslot release tarball (will call it 2.2), and I'll=20
post that sparately.

Regards

=2D --=20
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
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBP0xHoV0dQ6uSmkYRAiDnAKCCcS1GaPZ+h1dh6w+arsXjW3PlLQCfRReq
XLJhHVHmmAhNFS7Ld2ozmMw=3D
=3DUCNP
=2D----END PGP SIGNATURE-----


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