Re: What are the arguments against this
On Nov 1, 10:54 pm, "Jim Langston" <tazmas...@rocketmail.com> wrote:
<parag_p...@hotmail.com> wrote in message
news:1193869961.246381.125040@e34g2000pro.googlegroups.com...
I am asking the forum to show me the reasons and arguments
that might have been around when C++ did not implement it. My
language has implemented classes to a great extent and now
this does not look like a good feature,
[...]
I think I finally understand. Instead of c1.print() you are doing
print(c1); Consider though.
[...]
There are a lot of other scenarios I could come up with where
it would be arbitrary which print was called. So you'd have
to come up with complicated rules as to which one is called
and why and it would just become a nightmare as code wouldn't
work as expected.
Not really. The difference is purely syntactic. Formally, one
could define the language so that f(a) and a.f() were synonyms;
one could even go further, and allow things like f(a, b) to be
written (a, b).f().
C++ doesn't do this, because it wants to stress the difference
between member functions and other functions. Ada 95 only
supports the f(a) notation---and f(a) in Ada 95 works exactly
like a.f() in C++.
Also, there may be print() declared in other places.
c1.print() states explicitly which print is to be called.
No more so that print(c1). In both cases, it depends on the
type of c1. And there's nothing fundamental which would prevent
it from depending on the dynamic type, although C++ doesn't
support it.
The real difference in C++ is that when I write c1.print(), the
print function can be resolved on the dynamic type of c1, and
can access private data. Other mechanisms can be conceived of
for both; Ada 95 doesn't have the c1.print() syntax, but
supports both virtual functions and private data.
There is already some confusion with polymorphism, why add
another layer into the pot? I don't know the original reason
this wasn't allowed, but I'm glad it wasn't.
There are arguments both ways. Is it normal that I have to use
a.f(), but g(a), when both f and g manipulate a, just because
f() is a member (and has access to private data), but g() isn't.
Or for a more complete example: is it normal that I have to
write someString.append( "abcd" ), but toUpper( someString )?
And what implications does this have for templates?
Having said that, I, too, find it more explicit to set the
"owning" argument off by putting it in front of the function, a
la C++.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34