> It’s become part of the “modern C++ dogma” that free functions are part of a
> type’s interface, just like public members. But some things that are part of a
> type’s interface, you call function-style; others, you call dot-style—and,
> because there’s no rhyme or reason behind the distinction, you just have to
> memorize which are which. And, when designing types, and protocols for those
> types to interact with, you have to pick one arbitrarily, and be careful to be
> consistent everywhere.
Is this really it though? I don't agree that "there's no rhyme or reason behind the distinction." In fact, it's probably because non-member functions improve encapsulation [1], and because it is not possible to calculate the length of an internal buffer in C++ from outside the class. Unlike in Python, you can't access "private" or implementation specific members in a C++ class, so getting the length of a list or vector is something that has to be part of the class. On the other hand, you can access elements of a class without needing the underlying implementation, so it's reasonable to write a find procedure that is separate from the class itself.
For this reason, you're not "pick[ing] one [protocol] arbitrarily," you're doing it to preserve encapsulation and thus have a stronger object orientation. Perhaps the author can shed some light on what they meant here.
Because len() is a global function. That's perfectly fine in an OO system (everything does not have to be an object, attribute or method). Sure, it's not as consistent as anything.len(), but it works just fine. That's often the reason why Ruby claims to be a cleaner OO implementation than Python.
To me, Python really shows its warts when reversing a string. Something you never do out side of school (or on big ending to little endinan conversions).
> type’s interface, just like public members. But some things that are part of a
> type’s interface, you call function-style; others, you call dot-style—and,
> because there’s no rhyme or reason behind the distinction, you just have to
> memorize which are which. And, when designing types, and protocols for those
> types to interact with, you have to pick one arbitrarily, and be careful to be
> consistent everywhere.
Is this really it though? I don't agree that "there's no rhyme or reason behind the distinction." In fact, it's probably because non-member functions improve encapsulation [1], and because it is not possible to calculate the length of an internal buffer in C++ from outside the class. Unlike in Python, you can't access "private" or implementation specific members in a C++ class, so getting the length of a list or vector is something that has to be part of the class. On the other hand, you can access elements of a class without needing the underlying implementation, so it's reasonable to write a find procedure that is separate from the class itself.
For this reason, you're not "pick[ing] one [protocol] arbitrarily," you're doing it to preserve encapsulation and thus have a stronger object orientation. Perhaps the author can shed some light on what they meant here.
EDIT: minor formatting of quote
[1] http://www.drdobbs.com/cpp/how-non-member-functions-improve-...