On Mon, 2002-09-09 at 22:15, Ricardo Kirkner wrote:
I am sorry to bother the
list with this question, but I could not find a satisfying answer
anywhere.
My question regards overloading operators. As far as I know, if
you want to overload some operator, it must be public and
static.
1. I dont understand why this have to be that
way I would guess that the
`static' requirement is for language simplification -- there is only one
(consistent) way for operators to be expressed. In C++, some operators
must be global (read: operator<<, operator>>). C# doesn't
have global scope, so class-static is the closest equivalent. Since some
operators would need to be class-static, it was probably more consistent to
just require that they all be class-static. That's my best guess,
anyway.
I have no idea
why `public' is required.
2. If I want to overload the
++ operator in a class that I dont want to be public, but internal or
private, how can I prevent someone from accessing a method (the ++ operator)
that has been defined public?
Question to ponder: how will they access the public method
if they can't access the class in the first place? Consider methods that
must be public, such as Object.ToString(). Is it a problem that this
method is public, even in your internal classes? Not usually --
non-internal users can't access the class, so the existence of a public
ToString() method shouldn't be a problem. The same should be true of any
operators.
(The answer to the
above question of accessing internal classes is simple, actually: use
Reflection and poke around... Alternatively, modify the runtime to
permit poking on internal data. It's hard to protect against the
runtime.... However, these ideas are not trivial,
and can probably be ignored most of the time.)
This is not really a clean solution, is
it? I mean, although I cannot access the class (so I dont have to worry about
the "public-nes" of the methods inside that class, it does not mean that it is
correct to force you to declare the method public. (although this could be, and
probably is, just a simplification made by the language designers)
However, the real question remains: why do you need an
assignment operator? Assignment operators are useful in C++ when
wrapping resources, such as memory, files, thread locks, etc., to make sure
that the resource is properly managed (in concert with the copy constructor
and destructor)... In C#, the garbage collector is used for resource
management, removing (what I've found) the greatest need for the trio of C++
copy constructor, assignment operator, and destructor. If you need
something more deterministic, the IDisposable interface/idiom is
appropriate.
I actually dont
have a need for an assignment operator, but I think it is really nice
if you can do something like
obj1 = obj2;
instead
of
obj1 = new ObjectType(obj2);
This whole issue
arises because c# treats objects as references to objects instead as the real
ones (not that I find this wrong). I think that if you use a language that tries
to be so simple as c# is, and that tries to "help" the programmer by simplifying
syntax, etc, then it is suspicious not being able to write a simple object
assignment (without having both variables referencing the same object.
Note that by simle I mean using the = operator). This could be just a
decision made by the folks who thought about the language (and then I could not
make anything about it, of course), so I dont want to make a big
discussion about this here (because it is really a C# topic and not mono
specific).
Finally, I want
to thank you Jonathan, for your comments, I believe they helped
With
regards,
Ricardo
Kirkner
|
