Re: Implicit overloads, non static

Chad Z. Hower aka Kudzu <cpub@xxxxxxxxx> wrote:
> Jon Skeet [C# MVP] <skeet@xxxxxxxxx> wrote in
> news:MPG.1ce4b1481690e3b998c09f@xxxxxxxxxxxxxxxxxxxx:
> > Any reason not to just use a property or method?
>
> For the non copy constructor behaviour, it might be considered a bit of
> syntactic sugar.
>
> For the *existing* copy constructor behavior in C#, there is of course no
> way to replace that with just a property.
>
> But the idea is that C# allows users to create new simple value (or complex
> classes) types, and easily allow them to interact with int and other. There
> are some examples in the help. The examples are good code, but they arent
> really good examples for showing their usefulness.

<snip>

Sure, and I can see the use occasionally - but I don't think *most*
devs need to overload operators.

<snip>

> I know Jon that your much more advanced than the majority of this group,
> but dont assume just because you've not seen or needed the usefulnes of
> something that it is inherently bad or unuseful. I dont use parts of the
> FCL, but that doesnt make them useless.

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#.

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.

> >> Anything can make your code uninintuitive, especially when abused. In
> >> fact if I want unintuitive code I can go to C++ (or just putz around
> >> with C#'s C style for loop, a never ending source of careless bugs). :)
> >
> > What kind of bug are you thinking of? I can't remember the last bug I
> > had due to a for loop itself...
>
> The conditions are often goofed up by developers depending on the base of
> the indexer 0 or 1, and its terminator (i<50, or i<=50).

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.

Personally I find while loops take much longer to check for that kind
of error.

> > useful, particularly those involving TimeSpan and DateTime, but they're
> > very rarely useful on a user basis, IMO.
>
> Thats not true. :) If you are a user who mostly uses classes, which in fact
> is the majority of users I agree. However if they are useful to the
> builders of the FCL, they are very useful to builders of other class
> libraries too.

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".

> > I would say that any assignment to a variable which only changes *part*
> > of the data associated with that variable counts as a bad move, myself.
>
> Quite possibly. It fully depends how its implemented.

No, it's a bad idea on principle, IMO.

> Imagine the BCD
> example above - imagine that it might be useful to on its constructor
> specify a size.
>
> BCD xValue = new BCD(10);
>
> xValue = 400;
>
> int i = 4;
>
> xSum = xValue + i;
>
> But when I do xValue = 400, the 10 argument will be lost because of copy
> constructor behavior.

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?

> Sure, the answer is make it a property but then the
> BCD loses its ability to work as a "simple" type. Im not saying whether or
> not such a feature is good or bad - as I said it made a mess in VB, but
> that was because of its poor handling of objects. But the current copy
> constructor behaviour is VERY good and in no way would I ever want to see
> that removed.

Not sure what copy constructor behaviour you mean - could you
elaborate?

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

Loading