Ernie Rael wrote:
> My primary concern is that a bound-object-method can be used anywhere a > func can be used. Passing it to an existing function that has an argument > declared "arg: func" or to a builtin that expects a funcref. I have one > case that might push the limit > > export def Log(msgOrFunc: any, category: string = '') > var msg_type = type(msgOrFunc) > ... > elseif msg_type == v:t_func We'll have to see what type() should return for something like this. Again, it should be similar to what is used for a partial. > > And there might be additional functionality, e.g. to get the > > object that has been bound to. > I was wondering about getting the object. If you can get the object, is is > possible to set the object? If there is something like > setboundobject(bound-object-method, object) I don't think so. It sounds like a corner case, not much practical use. You can get the dict from a partial with get(). You can change it with function(), but there is no type checking at all. When using an object instead of a dict type checking would be very relevant. > and if the type of object must be assignable to the original object type, > then you you have a variable which is similar to a c++ "pointer to a member > function" except that it includes the object. This would seem to satisfy > the clamoring for using a method as a value. I guess the object could be > any arbitrary type, but that feels much more complicated. The object would need to match what the method is expecting. With inheritance this isn't simple. > > If you mean, whether the type declaration needs to be different, I'm not > > sure. Currently a partial isn't declared differently from a function > > reference, it might be possible to not have a separate type declaration > > when an object is bound to a function. But since the functionality is > > different, it might be useful to declare the type in a way that makes > > clear this functionality is available. > Is type being used imprecisely? (Like declare versus define) > I can see defining a bound object method differently > var F: func > F = bindobjectmethod(obj, method) > which wouldn't affect any existing code. But if the resulting type > is not t_func that presents compatibility/usage problems. Currently type() only indicates the basic type. For a function it doesn't mention the argument or return types. This most likely won't change and there isn't really a reason to add the bound object type. typename() is more specific. It likely should mention the class of the bound object. -- hundred-and-one symptoms of being an internet addict: 50. The last girl you picked up was only a jpeg. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20230521165928.5E3451C0F38%40moolenaar.net.
