Re: Implicit overloads, non static

Chad Z. Hower aka Kudzu <cpub@xxxxxxxxx> wrote:
> Jon Skeet [C# MVP] <skeet@xxxxxxxxx> wrote in
> news:MPG.1ce5ad9686c4495098c0a4@xxxxxxxxxxxxxxxxxxxx:
> > Sure, and I can see the use occasionally - but I don't think *most*
> > devs need to overload operators.
>
> No, they dont. But most developers dont build component sets - but Im sure
> glad they are there for the developers of the FCL to make the FCL easier
> for us to use - and for developers like myself who build FCL like libraries
> that others (And myself) use.

I'm glad they're available - but I'm also glad they're not flexible
enough to allow really nasty abuse.

> > I didn't say they were useless, but I would certainly take issue with
> > your claim that they're a "*very* important" feature of C#.
>
> They are - becuase the FCL is written in C#.

Much of it is, yes. There's no need for it to all be, however.

> And since we use the FCL -
> that makes it important. Without such, the FCL would not be as nice as it
> is for us to use, and C# would be like the old VB. A class USING language,
> but not a good class building language.

Put it this way - Java doesn't have operator overloading, but given the
choice between introducing that or introducing something similar to the
C# "using" statement, I'd go for the latter any day. Events, properties
and delegates would be higher up my list than operator overloading,
too. I'm happy enough calling methods rather than using operators when
I need to - it's never been a real headache for me in Java.

Reasonably important, maybe, but *very* important (your emphasis, not
mine)? Not really - not for me as either a class library user or
creator.

> > Going back to your original question, however, the ability to set only
> > part of a value on assignment is something which I believe would
> > *always* be better done with a property or method.
>
> Quite possibly - I didnt dispute that. I just wanted to verify that my
> findings were correct in that it didnt exist.

Well, you've disputed whether it's a matter of implementation rather
than principle. The fact that you'd *like* to do something which to me
seems completely abhorrent suggests that we've got a significant
disagreement.

> > Just how often is often? As I say, I can't remember the last time I
> > wrote such a bug - and come to think of it, I can't remember the last
> > time I saw one in a colleague's code either.
>
> I work with a lot of teams - and I see it fairly enough to know its a
> roach. Ive also seen the most experienced C++ developers make this mistake
> too.

I guess we can only talk about our own experiences, however different
they may be. The discrepancy does seem very odd though - I wonder what
the cause is.

> > Personally I find while loops take much longer to check for that kind
> > of error.
>
> Not simple indexers.
>
> for (int i = 1; i <= 5; i++)
> Console.WriteLine(i);
> }
>
> for (int i = 1 to 5)
> Console.WriteLine(i);
> }
>
> Only a diehard C++ developer (Which most are) would say the first one is
> simpler to understand. I dont dispute its more expandable, but 99% of the
> time thats never needed.

Sure, that's clearer - but I wasn't disputing that. You said you prefer
your developers to use while loops, and I was saying that I find them
harder to read than for loops. Maybe we're talking at cross-purposes
though.

> > Sure - so they're very rarely useful. They may be very useful to a very
> > few people, but I think that comes under "very rarely useful on a user
> > basis".
>
> DIRECTLY maybe. But you USE the FCL. So indirectly they are VERY useful.

Only if you'd really find life hard without them. I don't find life
hard in Java where I don't have them, therefore they're not that
important to me.

> >> Quite possibly. It fully depends how its implemented.
> >
> > No, it's a bad idea on principle, IMO.
>
> If its a bad idea - then so are the implicit convertors.

And for almost every use, I'd go along with that. Other than the types
defined in the language spec, I think it's pretty much always a bad
idea to have implicit conversion. Being able to provide *explicit*
conversion operators is not quite so bad, although it should still be
used with a lot of care.

> > And that's exactly what I'd *always* expect. If I tell a variable to
> > have a new value, it had better *have* a new value afterwards. That's
> > what I expect. It's a simple rule - why try to break it and confuse
> > people?
>
> It DOES have a new value- but its a value type - in fact its not even a
> "value", it just mimics a value.

But that new value isn't entirely derived from the expression on the
right hand side of the "=" - and that's *very* counter-intuitive. Not
due to implementation, but due to the very principle of the idea.

> But again - see above, Im not disputing
> that default properties would be a good thing. My point of disagreement
> with your statements regards existing behaviour in C# that you find little
> use for and thus label as unimportant.

No, I think we're disagreeing more fundamentally. Your examples have
shown that you think it's not always a bad idea to violate the
principle that if I do:

<variable> = <expression>;

I should be able to look at <expression> and completely know the value
of the variable. That's not a matter of what's important or not, it's a
case of what violates entirely reasonable assumptions that pretty much
every developer makes subconciously all the time.

> > Not sure what copy constructor behaviour you mean - could you
> > elaborate?
>
> Copy constructor is what implicit conversions cause.
>
> BCD = 4;
>
> This actually causes a new BCD instance to be created, and 4 is passed to
> it.

Right. I'm not sure I'd call that a copy constructor myself, but that's
not terribly important. (I usually wouldn't use the phrase "copy
constructor" outside C++, and then only when the parameter to the
constructor was of the same type as the object being constructed.)

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Implicit overloads, non static
    ... No, they dont. ... But most developers dont build component sets - but Im sure ... glad they are there for the developers of the FCL to make the FCL easier ... > Sure - so they're very rarely useful. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Help!!!
    ... > I think part of the problem with Delphites coming to the .NET platform ... or think back to when you first started playing with the VCL ... Exactly, .NET through the use of FCL, allows VB and VC++ developers to ...
    (borland.public.delphi.non-technical)
  • Re: Does VCL have a future?
    ... functionality it provides the developer than does the VCL ... It probably does matter for the sake of feature comparison, ... since parts of VCL.NET require FCL, it's probably not a meaningful issue. ... makes sense for .NET developers to gain some familiarity with the FCL. ...
    (borland.public.delphi.non-technical)
  • Re: immutable
    ... An class whose data is provided in the constructor and has only ... read-only properties is immutable. ... And where is there a method changing the immutable value in my ... Developers for exciting positions in medical product ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Invoking a Static Method in a Static Class
    ... Invoke, passing null as the object reference. ... Developers for exciting positions in medical product ... And again, Since this is a static class with no constructor, I know that it ... Would this be the appropriate set of instructions to use on an Instance class? ...
    (microsoft.public.dotnet.languages.csharp)
Loading