HN Explorer

Ask HN: Does anyone distinguish methods names for indirect/direct objects?

2 points by cammil ↗ HN
There is much advice on naming and many conventions proposed in various languages. However, I am yet to come across any suggestions regarding naming for indirect/direct objects.

It occurs to me that methods of an object should be named in such a way that the method is the verb, and the object is the direct object. The parameters of course would be the indirect objects.

This seems natural to me but I rarely see it. Presumably because it is easier to ignore this restriction. I was curious as to whether there are any guidelines on this, or if anyone else has had any experience of utilising other less common naming conventions.

7 comments

[ 2.9 ms ] story [ 30.3 ms ] thread
thristian
I'm afraid I don't understand the question. You mean naming variables and methods so you can say things like this?

    department.adopt(newEmployee)
Seems to me that's a very common convention and has the Department instance as the direct object, and the Employee instance as the indirect object as you suggest. If that's correct, can you give an example of conventions that "ignore this restriction"?
cammil
Indeed. A convention that recommends the following is not written:

newEmployee.adoptBy(department)

limmeau
What about

newEmployee.join(department)

?

cammil
That follows the subject.verb(object) pattern so that would be fine.
limmeau
Do you mean direct/indirect objects as in French grammar: Le père donne la clé à la voisine ("The father gives the key to the neighbour"; father: subject, key: direct object, neighbour: indirect object)?

Corresponding OO code:

        father.give(key, neighbour)
And objects (in the grammatical sense) with preposition could be understood to correspond to keyword arguments:

        father.give(key, to=neighbour)
Now if we introduced cases to a programming language...
cammil
Yes, that is actually what I meant to convey. I should have said that methods should be verbs, and that they should be methods of the subject (not direct object). And that parameters should be linguistic objects, direct or otherwise.

PS. Cases, I hadn't even considered that. My feeling is that methods should be imperatives. They tend to be anyway. I haven't given much thought though.

limmeau
Cases and prepositions both signify into which 'slot' of a verb this object goes. From that perspective, if prepositional objects correspond to keyword args, so do cases.

On the other hand, a case is a form of the noun-phrase which can be constructed without looking at the predicate. I see a similarity to the address operator in C:

foo(bla, &blub)

means that bla is passed in value-case, whereas blub is passed in reference-case.