> Dan: >> Yep. There should be a can operator, though I'm not sure how often one >> wants to check for the existence of a method in an object without >> calling it. But no reason not to. More for rev 2.
Adriano: > I think what Jonathan asked for was an operator for returning a method > (as an object) > which can be invoked later with some arguments (or even applied with a > partial list > of arguments for currying). > This would be a lot more useful than a yes-or-no answer about the > existence of a method. I think just knowing it exists would be useful (ala java's "reflection") since you might want to know if it exists in order to do some set of calculations before calling it, since if it doesn't exist there's a better/different set of calcs you need to do that have no use for the first set. I also like currying functions, which I can see kindof wanting the funcall pointer (although ... would it also need some way of garnering what the parameterlist (quantity or types) is?) ... Luckily the former (yes/no) can be easily inferred from the latter (funcall ptr) simply by "if the pointer is null, that'd be a no" :) although, with the parameter info that may be encapsulated and returned in some way with the fptr (if any is returned, that is), it might also be beneficial to have a seperate opcode for "just tell me if it exists", depending on how much overhead the fptr & param-info incurs ... Short version: I think both are good. Yes/No is inferrable from a pointer, but if the pointer has to include other information (and thus be a full PMC or however, precisely) seperate might be good. --attriel
