Hey Jan,
On 8 September 2010 09:50, Jan Kanis <j...@jankanis.nl> wrote:
> About the events: I think copied functions should not be connected to their
> parents events, otherwise the original use case of 'extending a function'
> doesn't work for event handlers. If function oldfoo is invoked on fooevent,
> and I want to have e.g.
>
> function newfoo
> oldfoo nondefaultparam
> end
>
> do the job instead, I want newfoo to be connected when fooevent fires, and
> not oldfoo, otherwise oldfoo is called twice.
>
Agreed! What was I thinking? That is much easier, and more sensible.
> But that again suggests that it might be handy to be able to edit the
> events a function is connected to after it has already been created. (just
> thinking.) Thinking some more, I wouldn't mind being able to easily see and
> set what functions are registered for an event handler.
>
Yes, this would be interesting... I'll see if I can get it showing what's
registered. If I get that far, it probably won't be a huge jump to
adding/removing (famous last words? :) ).
> Also, I think a function copy feature is better than a rename feature. If
> you have copy, you can do rename by removing the old one. If you only have
> rename, you can't get copy behaviour without ugly eval hacks. And it might
> be helpful to start with the code of the old function when you funced the
> new function. I think it's a bit overkill to have both a copy and a rename,
> but I don't care a lot.
> Though I don't know how hard it is to program function copying.
>
I pretty much had to implement function copying to add renaming. So
assuming I got it correct this time (ignoring the event stuff), this will be
quite easy to add. Thought I'd test the waters with one thing at a time,
until I got my "fish legs". :)
> Btw, I've added you to the fish-developers group, so you can put your
> branch directly in the 'real' repo.
>
> Jan
>
>
Wow, thanks. I'll try not to break too many things.
Cheers,
Chris.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Fish-users mailing list
Fish-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fish-users
