> If there were a way to edit a functions event bindings, what happens with > the event bindings matters a little less. One could argue both ways on what > copying should do with the events in that case. One could argue that a full > copy of a function should include the event bindings as they are part of the > function. But I can't really think of any use cases where the copying of > event bindings would be usefull, so I currently don't think they should be > copied. Can anybody think of any use cases where this would be desired? > >
My thinking is it's probably safer to default to copying without the original events. That way the worst that happens is that the new copy *isn't* called when an event fires. So nothing changes. The alternative, copying with the same events hooked up, is that they'll be called unintentionally. So something *accidentally* changes. Giving an explicit override, or letting the user set whatever they like afterwards, makes it all their fault. Which I think is ok. :) First, what do you want to do with the -s, -p, -j and -v options? > Oh, those are just for the other notification types that “function” can sign up for: --on-signal, --on-process-exit, --on-job-exit, --on-variable, as well as--on-event . As well as being more specific, it also tells the funcevents/listeners command how to treat the parameter (eg. Is this a variable or event name? ). This problem goes away if we only care about the guys in --on-event, but they're all accessed the same way, so I figured if I was doing it for one, may as well plug in the others. That's when the sticky syntax and scary music got me. :) > > I intuitively agree this should probably be the job of functions, but if > so, deciding what options to use is not so straight forward. 'functions' is > already used to edit a different 'property' of fuctions: the description. > But given that my 'functions' only has six options in it's help page, which > is a very small number compared to the average gnu utility, I am not in > favor of overloading one of those like -q just yet. > > There's also some presendence for the new builtin variant, but if that one > is chosen I'd say it should be called 'funcevent' or something similar. > There are several builtins starting with 'func' that deal with fish > functions. The only non fish func* command on my path is something called > function_grep.pl which I've never heard of and is apparently part of wine. > > > IMHO the choice between these two options depends in large part on this > question: > (Assuming optimistically that fish will once be as popular as bash is > today,) Will there be a need in the future to add lots more operations > dealing with functions and/or events, or will the basic add/remove/list > operations be mostly all we need? If the former is true, it makes sense to > make a separate builtin to deal with event bindings. In the latter case, it > probably makes sense to keep the command namespace clean and add the > functionality to 'functions'. > Of course, the answer to that question is unknown and very hard to predict. > > > I guess the separate command gives some room to grow (though, I can't really think of anything either, beyond add/remove/list...), and also leaves “functions” alone to view/manipulate the actual list of function names, rather than the events of any particular function. Maybe something like: Listing: > funcevents --on-signal=SIGHUP foo_function Adding: > funcevents --on-event=BAR_EVENT foo_function Removing: > funcevents -r --on-signal=SIGHUP foo_function This doesn't feel like it's "resisting" as much as functions was... If this makes sense, I'll see if I can make this work. Cheers, Chris.
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
