The pdds are somewhat unclear, what these vtables should precisely do. e.g.: INTVAL does(INTERP, PMC* self, STRING* method) Determine whether the PMC implements the interface
"Interface" is not in the glossary in pdd015 nor specified elsewhere.
An interface is just a known collection of methods.
I would like to have some vtables to do:
- isa("array") # any kind of array (or is this "does"?)
Probably does.
- can("get_string") # this class or one of the parents but not a dummy in default implements "get_string". (or is this "does"?)
This is can, if you're looking for the get_string method specifically.
The full explanation is:
can - checks to see if an object can perform a specific, single method. (A parent class may provide them)
isa - checks to see if the named class is in the inheritance hierarchy for the object
does - checks to see if the object implements the named collection of methods. (Often, but not always, called an interface)
Does is a superset, of sorts, of can. The problem with checking for a single method by name is that it's possible (potentially likely) that the method you find isn't the method you want, since names short enough to be useful are short enough to be confusing. ("rotate" is a perfectly good name for a method that does matrix manipulation, image manipulation, and UI element manipulation -- just because an object says it can rotate doesn't mean that it actually does what you want)
It's certainly possible to have multiple interfaces with the same name that do different things, but that's less likely, and it still gives the programmer another way to make sure code'll behave the way he/she/it wants.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
