Implicit overloads, non static

[Chad Z. Hower aka Kudzu]

I have defined some implicit convertors so that I can do:

MyStruct x = 4;

The implicit convert the 4 into MyStruct. But its essentially a copy
constructor and thus if I had:

MyStruct x;
x.SomethingElse = 5;
x = 4;

Now x.SomethingElse will be 0, because x is a new instance. Ok - all proper
and as exected - no questions here.

What I would *like* to do is this. Have the 5 update the object = not replace
it. I shudder to compare this to VB's old "default properties" but
essentially soemething like that.

This is really a non static overload, and as I understand it, C# does not
support this correct? And also there is no way to access the current instance
in the implicit convertors?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Empower ASP.NET with IntraWeb

http://www.atozed.com/IntraWeb/

[Bruce Wood]

Re: Implicit overloads, non static

> What I would *like* to do is this. Have the 5 update the object = not
replace[color=blue]
> it.[/color]

Could you elaborate? I have no idea what you mean by this.

[Jon Skeet [C# MVP]]

Re: Implicit overloads, non static

Chad Z. Hower aka Kudzu <cpub@hower.org > wrote:[color=blue]
> I have defined some implicit convertors so that I can do:
>
> MyStruct x = 4;
>
> The implicit convert the 4 into MyStruct. But its essentially a copy
> constructor and thus if I had:
>
> MyStruct x;
> x.SomethingElse = 5;
> x = 4;
>
> Now x.SomethingElse will be 0, because x is a new instance. Ok - all proper
> and as exected - no questions here.
>
> What I would *like* to do is this. Have the 5 update the object = not replace
> it. I shudder to compare this to VB's old "default properties" but
> essentially soemething like that.
>
> This is really a non static overload, and as I understand it, C# does not
> support this correct? And also there is no way to access the current instance
> in the implicit convertors?[/color]

I don't believe there's any way to do this, and frankly I'm glad -
things like the above would make your code *very* unintuitive, IMO.
Heck, even implicit conversions are bad enough in that respect, without
further abuse...

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Chad Z. Hower aka Kudzu]

Re: Implicit overloads, non static

"Bruce Wood" <brucewood@cana da.com> wrote in news:1115311764 .128722.235310
@o13g2000cwo.go oglegroups.com:[color=blue]
> Could you elaborate? I have no idea what you mean by this.[/color]

Im not sure I can elaborate much more - its pretty detailed. :)


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Get your ASP.NET in gear with IntraWeb!

http://www.atozed.com/IntraWeb/

[Chad Z. Hower aka Kudzu]

Re: Implicit overloads, non static

Jon Skeet [C# MVP] <skeet@pobox.co m> wrote in
news:MPG.1ce477 13d0c5316398c09 b@msnews.micros oft.com:[color=blue]
> I don't believe there's any way to do this, and frankly I'm glad -[/color]

I have mixed feeling on it. In VB (ack!) it certainly caused a lot of
issues, but that was because VB never handled objects properly.

But the fact that VS already includes support for implicits, etc I think it
might be a good extension but havent fully thought out all the consequences
yet. At this point I just wanted to confirm that it does not exist, so I
can proceed with what I have.
[color=blue]
> things like the above would make your code *very* unintuitive, IMO.
> Heck, even implicit conversions are bad enough in that respect, without
> further abuse...[/color]

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). :) But implicit
operators do not themselves make code unintuitive - the user does. Implicit
operators are a *very* important feature of C# IMO and have proven
incredibly useful in practice.

Operator overloads can make a mess in the wrong hands too. But Id much
rather have the scalpel that C# is, than a chain saw. C# is very nice in
that *most* of it is implemented in "itself" rather than compiler magic,
although a lot of that remains too.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Make your ASP.NET applications run faster

http://www.atozed.com/IntraWeb/

[Jon Skeet [C# MVP]]

Re: Implicit overloads, non static

Chad Z. Hower aka Kudzu <cpub@hower.org > wrote:[color=blue]
> Jon Skeet [C# MVP] <skeet@pobox.co m> wrote in
> news:MPG.1ce477 13d0c5316398c09 b@msnews.micros oft.com:[color=green]
> > I don't believe there's any way to do this, and frankly I'm glad -[/color]
>
> I have mixed feeling on it. In VB (ack!) it certainly caused a lot of
> issues, but that was because VB never handled objects properly.
>
> But the fact that VS already includes support for implicits, etc I think it
> might be a good extension but havent fully thought out all the consequences
> yet. At this point I just wanted to confirm that it does not exist, so I
> can proceed with what I have.[/color]

Unless I've missed something big, it doesn't, for which I'm heartily
glad.

Any reason not to just use a property or method?
[color=blue][color=green]
> > things like the above would make your code *very* unintuitive, IMO.
> > Heck, even implicit conversions are bad enough in that respect, without
> > further abuse...[/color]
>
> 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). :)[/color]

What kind of bug are you thinking of? I can't remember the last bug I
had due to a for loop itself...
[color=blue]
> But implicit
> operators do not themselves make code unintuitive - the user does. Implicit
> operators are a *very* important feature of C# IMO and have proven
> incredibly useful in practice.[/color]

I can't remember *ever* writing one, in fact... the predefined ones are
useful, particularly those involving TimeSpan and DateTime, but they're
very rarely useful on a user basis, IMO.
[color=blue]
> Operator overloads can make a mess in the wrong hands too. But Id much
> rather have the scalpel that C# is, than a chain saw. C# is very nice in
> that *most* of it is implemented in "itself" rather than compiler magic,
> although a lot of that remains too.[/color]

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.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Steve Walker]

Re: Implicit overloads, non static

In message <MPG.1ce4b14816 90e3b998c09f@ms news.microsoft. com>, Jon Skeet
<?@pobox.com.in valid> writes[color=blue]
>Chad Z. Hower aka Kudzu <cpub@hower.org > wrote:[/color]
[color=blue][color=green]
>> But implicit
>> operators do not themselves make code unintuitive - the user does. Implicit
>> operators are a *very* important feature of C# IMO and have proven
>> incredibly useful in practice.[/color]
>
>I can't remember *ever* writing one, in fact... the predefined ones are
>useful, particularly those involving TimeSpan and DateTime, but they're
>very rarely useful on a user basis, IMO.[/color]

The only one real use I've found is in a class a bit like this:

public abstract class ParameterBase
{
protected SqlParameter underlyingParam eter;
......
public static implicit operator SqlParameter (ParameterBase p)
{
return p.underlyingPar ameter;
}
}

The point of this is simply to fake polymorphic behaviour. This
originally came about from a desire to provide a library of custom
parameters mapping directly to a set of SQLServer user defined data
types. What I really wanted to do was subclass SqlParameter, but it's
sealed. This solution allows:

cmd.Parameters. Add(new IPAddressParame ter("@RemoteAdd r", remoteAddr));

and, for some subclasses which fix the parameter name:

cmd.Parameters. Add(new PortalIDParamet er(portalID));

The following would be more explicit but, in this situation, less tidy:

cmd.Parameters. Add((SqlParamet er)new PortalIDParamet er(portalID));
cmd.Parameters. Add((new PortalIDParamet er(portalID)).S qlParameter);

It isn't a design I would have used had SqlParameter or SqlCommand been
under my control, though, and it isn't the kind of thing I would do for
a domain model class.

--
Steve Walker

[Chad Z. Hower aka Kudzu]

Re: Implicit overloads, non static

Jon Skeet [C# MVP] <skeet@pobox.co m> wrote in
news:MPG.1ce4b1 481690e3b998c09 f@msnews.micros oft.com:[color=blue]
> Any reason not to just use a property or method?[/color]

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.

But imagine that I need a BCD class. I can make it a value type (struct)
(or a classs).

BCD xValue;

xValue = 400;

int i = 4;

xSum = xValue + i;

This all works and is much cleaner, because of the implicit conversions
that you didnt find a use for. :) This is in fact a very simplistic
example, there are much more advanced and better uses, one of which I'll be
writing a paper on soon as Im presenting on it at SDA Asia in Singapore
this month.

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.
[color=blue][color=green]
>>
>> 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). :)[/color]
>
> What kind of bug are you thinking of? I can't remember the last bug I
> had due to a for loop itself...[/color]

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). Sure we all know
the proper format of the c style for, but its a very common source of bugs,
and Im even ocassionaly caught by it. While I dont mind that they have it
in C#, I much prefer my developers use while/repeats in the more advanced
permutations of the for. For the 99% of the simple cases, it would be much
better if C# had also added a simple:
for int i = 1 to 50 step 2 etc.. Maybe a C style mutation would be more
like:
for (int 1, 1, 50, 2) or something, but none the less would reduce bugs as
its harder to make "stupid" mistakes this this form, and the 1-2% cases
that fall outside this construct users could use the existing for, or a
repeat style loop.
[color=blue]
> I can't remember *ever* writing one, in fact... the predefined ones are[/color]

See above.
[color=blue]
> useful, particularly those involving TimeSpan and DateTime, but they're
> very rarely useful on a user basis, IMO.[/color]

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.
[color=blue]
> 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.[/color]

Quite possibly. It fully depends how its implemented. 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. 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.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Develop ASP.NET applications easier and in less time:

http://www.atozed.com/IntraWeb/

[Jon Skeet [C# MVP]]

Re: Implicit overloads, non static

Chad Z. Hower aka Kudzu <cpub@hower.org > wrote:[color=blue]
> Jon Skeet [C# MVP] <skeet@pobox.co m> wrote in
> news:MPG.1ce4b1 481690e3b998c09 f@msnews.micros oft.com:[color=green]
> > Any reason not to just use a property or method?[/color]
>
> 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.[/color]

<snip>

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

<snip>
[color=blue]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
> >> 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). :)[/color]
> >
> > What kind of bug are you thinking of? I can't remember the last bug I
> > had due to a for loop itself...[/color]
>
> 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).[/color]

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.
[color=blue][color=green]
> > useful, particularly those involving TimeSpan and DateTime, but they're
> > very rarely useful on a user basis, IMO.[/color]
>
> 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.[/color]

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".
[color=blue][color=green]
> > 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.[/color]
>
> Quite possibly. It fully depends how its implemented.[/color]

No, it's a bad idea on principle, IMO.
[color=blue]
> 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.[/color]

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?
[color=blue]
> 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.[/color]

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

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Daniel O'Connell [C# MVP]]

Re: Implicit overloads, non static

>[color=blue]
> 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). Sure we all know
> the proper format of the c style for, but its a very common source of
> bugs,
> and Im even ocassionaly caught by it. While I dont mind that they have it
> in C#, I much prefer my developers use while/repeats in the more advanced
> permutations of the for. For the 99% of the simple cases, it would be much
> better if C# had also added a simple:
> for int i = 1 to 50 step 2 etc.. Maybe a C style mutation would be more
> like:
> for (int 1, 1, 50, 2) or something, but none the less would reduce bugs as[/color]

foreach ( int x in 1..50 : 2)

;)

[Chad Z. Hower aka Kudzu]

Re: Implicit overloads, non static

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
news:udyl5TmUFH A.612@TK2MSFTNG P12.phx.gbl:[color=blue]
> foreach ( int x in 1..50 : 2)[/color]

You made my heart jump for a minute - thought there was something in C# I
didnt know about!

But I certainly would not argue with such a syntax - in fact when I get
sometime I'll show you whave I've actaully done. :)


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Make your ASP.NET applications run faster

http://www.atozed.com/IntraWeb/

[Chad Z. Hower aka Kudzu]

Re: Implicit overloads, non static

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
news:udyl5TmUFH A.612@TK2MSFTNG P12.phx.gbl:[color=blue]
> foreach ( int x in 1..50 : 2)[/color]

I actually had this idea before you posted - but figured Id save it for a
rainy day. But it was very easy, took me all of 5 minutes so I decided to
do it.

foreach (int i in new Counter(1, 5)) {
Console.WriteLi ne(i.ToString() );
}

Yes it works. :) This is the really neat part of C# and .NET, its very
extensible. Of course this is slower - but unless you have a very tight
running loop, the difference will never ever be noticed. The counter class
is below for the curious. I havent adapted it to count down or anything.


Counter class:

public class Counter {

// This enumerator is not thread safe or multi enumerator safe.
// But its usage pattern does not require such.
public class CounterEnumerat or {
private Counter _Counter;

internal CounterEnumerat or(Counter aCounter) {
_Counter = aCounter;
}

public bool MoveNext() {
_Counter._Curre nt += _Counter._Step;
return _Counter._Curre nt <= _Counter._End;
}

public int Current {
get { return _Counter._Curre nt; }
}
}

private int _Begin;
private int _End;
private int _Step;
private int _Current;

public Counter(int aBegin, int aEnd) : this(aBegin, aEnd, 1) {
}

public Counter(int aBegin, int aEnd, int aStep) {
_Current = aBegin - 1;
_Begin = aBegin;
_End = aEnd;
_Step = aStep;
}

public CounterEnumerat or GetEnumerator() {
return new CounterEnumerat or(this);
}


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Develop ASP.NET applications easier and in less time:

http://www.atozed.com/IntraWeb/

[Chad Z. Hower aka Kudzu]

Re: Implicit overloads, non static

Jon Skeet [C# MVP] <skeet@pobox.co m> wrote in
news:MPG.1ce5ad 9686c4495098c0a 4@msnews.micros oft.com:[color=blue]
> Sure, and I can see the use occasionally - but I don't think *most*
> devs need to overload operators.[/color]

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.
[color=blue]
> 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#.[/color]

They are - becuase the FCL is written in C#. 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.
[color=blue]
> 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.[/color]

Quite possibly - I didnt dispute that. I just wanted to verify that my
findings were correct in that it didnt exist.
[color=blue]
> 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.[/color]

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.
[color=blue]
> Personally I find while loops take much longer to check for that kind
> of error.[/color]

Not simple indexers.

for (int i = 1; i <= 5; i++)
Console.WriteLi ne(i);
}

for (int i = 1 to 5)
Console.WriteLi ne(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.
[color=blue]
> 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".[/color]

DIRECTLY maybe. But you USE the FCL. So indirectly they are VERY useful.
[color=blue][color=green]
>> Quite possibly. It fully depends how its implemented.[/color]
>
> No, it's a bad idea on principle, IMO.[/color]

If its a bad idea - then so are the implicit convertors.
[color=blue]
> 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?[/color]

It DOES have a new value- but its a value type - in fact its not even a
"value", it just mimics a value. 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.
[color=blue]
> Not sure what copy constructor behaviour you mean - could you
> elaborate?[/color]

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.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Empower ASP.NET with IntraWeb

http://www.atozed.com/IntraWeb/

[Jon Skeet [C# MVP]]

Re: Implicit overloads, non static

Chad Z. Hower aka Kudzu <cpub@hower.org > wrote:[color=blue]
> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
> news:udyl5TmUFH A.612@TK2MSFTNG P12.phx.gbl:[color=green]
> > foreach ( int x in 1..50 : 2)[/color]
>
> I actually had this idea before you posted - but figured Id save it for a
> rainy day. But it was very easy, took me all of 5 minutes so I decided to
> do it.
>
> foreach (int i in new Counter(1, 5)) {
> Console.WriteLi ne(i.ToString() );
> }
>
> Yes it works. :) This is the really neat part of C# and .NET, its very
> extensible. Of course this is slower - but unless you have a very tight
> running loop, the difference will never ever be noticed. The counter class
> is below for the curious. I havent adapted it to count down or anything.[/color]

It's even easier with "yield" in 2.0:

public class Counter : IEnumerable
{
int from;
int to;

public Counter (int from, int to)
{
this.from = from;
this.to = to;
}

public IEnumerator GetEnumerator()
{
for (int i = from; i <= to; i++)
{
yield return i;
}
}
}

(I missed out the step part for clarity - it's obvious how you'd put it
in.)

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Chad Z. Hower aka Kudzu]

Re: Implicit overloads, non static

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
news:udyl5TmUFH A.612@TK2MSFTNG P12.phx.gbl:[color=blue]
> foreach ( int x in 1..50 : 2)[/color]

http://www.codeproject.com/useritems/ForCSharp.asp

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Get your ASP.NET in gear with IntraWeb!

http://www.atozed.com/IntraWeb/