Actually, that's exactly how I'd describe a method: a function written by a programmer (or programming team), but for that object and for no other. That's where my assumptions used to lead me astray. For example: I had learned of a "method" (which I thought of as a VBA function) that I could use to determine whether a certain item exists in a Dictionary object:Very good; that's useful. So later on I try to use this Exists "function" in other places in my program:...and I get an error: This object does not support this property or method.

For years that drove me crazy. Why could I use the Exists function one time and not another?! It wasn't until later—not until I finally wrote my own object, in fact—that I saw, very simply, that Exists was not a function of the VBA language, nor even a function of the Excel application, but a function of the Dictionary object. The folks who created the Dictionary object wrote an Exists method into it; but the folks who wrote the Worksheets collection in Excel did not—and a method exists only in the object it's written for.

Likewise, when you're adding an item to most Collections, the first argument for the Add method is the item you're adding and the second item is the optional key. But in a Dictionary's Add method, the first argument is the required key and the second is the contents. Different objects, different rules. Different subroutines, in fact, despite the fact that they have the same name.

It's my understanding that this is common to object-oriented programming, not specific to one language or environment or another. If this VFP thingy (is that Visual FoxPro?) had a great deal of consistency in the methods between various objects, it's probably because the architects decided to maintain an overall design philosophy rather than let each item be constructed from scratch.

I don't usually let it bother me, now. When I decided I wanted an Exists method for Collections, I went ahead and wrote it as a function and use it all the time, now.