Re: Need new name for connect_object()
| From: | Andrei Zmievski | Date: | Mon, 21 Mar 2005 21:52:32 +0000 |
| Subject: | Re: Need new name for connect_object() | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.gtk.dev |
| Request: | Send a blank email to php-gtk-dev+get-1038@lists.php.net to get a copy of this message | ||
Considering that the first iteration of PHP-GTK was half-assed anyway, I'd like to get things mostly "right" this time.
As far as separate manuals, heck, yes. I thought Jeremy & Christian were working on something?
-Andrei
On Mar 21, 2005, at 1:49 PM, Steph wrote:
Everyone's going to love that sooooooooo much :) but I think you're right, because it doesn't look as if there's going to be a lot of BC-friendliness here anyway. Which brings us back to the question of separate manuals... ----- Original Message ----- From: "Andrei Zmievski" <andrei@gravitonic.com> To: "Madeleine D." <mmdrake@bctonline.com> Cc: "PHP-GTK Dev" <php-gtk-dev@lists.php.net> Sent: Monday, March 21, 2005 9:40 PM Subject: Re: [PHP-GTK-DEV] Need new name for connect_object()Note that none of the ones I proposed have the current behavior of connect_object(), actually. I'd like to deprecate that method completely and make people use the new three. -Andrei On Mar 21, 2005, at 1:39 PM, Madeleine D. wrote:A - I see your point. I've never had a call yet to come up with the simple version, so I didn't even think of it. But, based on the past few months, it's probably out there, waiting, in my future. So, I guess my vote would be for 3 different ones - for clarity's sake. Madeleine D. At 01:02 PM 3/21/05 -0800, you wrote:-- PHP-GTK Development Mailing List (http://gtk.php.net/) To unsubscribe, visit: http://www.php.net/unsub.phpNot really. What it does currently is "omit" the signal object, passes the rest of parameters, adding on the user specified-ones at the end. So, if originally the parameters to be passed were ($signal_widget, $col, $row), and we connect it as: $w->connect_object('foo', 'myfoo', $myobj); the parameters it'll pass are ($col, $row, $myobj). I guess what I am asking is whether this behavior is useful at all, or if we would rather really substitute the user specified object instead of the signal one, or not pass any signal parameters at all, or what. Or maybe have a connection function for all three cases: 1) connect normally: pass signal widget plus additional signal-specific parameters 2) connect replace: substitute user-specified object instead of the signal one, and pass additional signal-specific parameters 3) connect simple: pass only user specified parameters -Andrei On Mar 21, 2005, at 11:29 AM, Madeleine D. wrote:I'm probably being too simplistic here, but what about connect_other() since it does the same things as connect, including parms, but it does it for another object. Madeleine D.