It's a bit ugly that it passes "this" in any of those cases since it's a codec and not a compilation handler. I'm not sure why it does that. Maybe it's to ensure that the __register_new_program callback can be called later on, but that's done through the codec object anyway. So I'd say the "this" passing should go away in the 'p', 'f' and 'o' cases instead.
One thing that perhaps should be done there is to add a compilation handler slot to the codec, so that one can be instantiated with a specific handler that it will pass on in those cases. I.e. so that the handler in effect in low_findprog also will be used in later resolv/findmodule/etc calls from the codec.
But how does the "this" passing complicate inheritance? If an inherited object instance is used then that one will also be passed on, which seems like the right thing to me.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-07-04 14:14: Subject: Re: Warnings from startup script
As opposed to a compilation handler, the codec isn't inherited when modules are resolved recursively. A codec is always chosen for decoding each string, so you can always select a suitable one depending on the source of the string.
Ok. The Pike codec seems to select "this" unconditionally though, so one needs to watch out if inheriting it as a base for a custom codec. (Hm, shouldn't it pass "this" to resolv() for the 'r' case as well? It seems inconsitent to do it only for 'p', 'o' and 'f'...)
Anyway, my point wasn't valid since the pike codec doesn't have any greater luck getting the real werror efun even if it's used on the pike dumps.
Yes, but that's an orthogonal problem. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)