Walter wrote:
> "Ilya Minkov" <midiclub@8ung.at> wrote in message
> news:b0h1eb$15pl$1@digitaldaemon.com...
> 
>>Say, is operator overloading possible on typedef-s? IMO it should.
> 
> 
> It is, and you're right. Overloading on typedefs is one of the major points
> of it.
> 

But then this means that Scott simply has to overload assignment for typedef "money". And that it doesn't make a difference whether one tries to assign a constant or a variable or an expression, it shouldn't be allowed on a typedef, reminding:
"don't forget to overload assignment, possibly making some changes to data to make a type work correctly!"

--"don't forget to call free..." :>

basically my position is this:

i can't imagine anyone ever saying, "gee, thank goodness the compiler forced me to write 'myFloat mf = (myFloat)0.0' because that really saved me from getting into trouble later on".  on the other hand, i can see lots of people saying, "Dammnit, i forgot to cast 0.0 to myFloat when i initialized my variable, arrggghhh, now where the hell was that..."  it won't be a big error surely, and not difficult to fix, but i don't see the point of forcing the programmer to have to do that.  i can see that it is indeed more conceptually pure to force the cast -- and you can work out the syntax of the cast yourselves, right now i don't care -- but i don't see any practical advantage to slavishly following the most conceptually pure paradigm in this instance.

> I still don't understand why you are using a typedef and not an alias ('alias' is almost directly equivilent to C 'typedef')

yes, i'm quite sure i want typedef, not alias. i want D-style typedef for all the other things it does for us, even if i really must cast literals. in fact, i'm not convinced i would even want to see alias in the final language, seems to me like it would hide errors.

> I use numeric typedef rarely, I don't see how typedef double money benifits the code in any way

I have used, and intend to continue using, numeric typedefs.  in C, they help to me keep track of my intentions.  in D they'd enforce those intentions.  the example of "typedef double money" was a simplistic, contrived example, the kind usually used for discussions like this.  a simplistic, contrived example of how that would help me is:

tyedef double money;
typedef double velocity;
void setVehicleVelocity(velocity v){...}
money getAccountBalance(){...}

setVehicleVelocity( getAccountBalance() ) // Error in D, legal in C

> if you look at it right you will see it is you that should bend and not
> the spoon !
> (even if the spoon is imperfect)
> creating special cases leads to more special cases and in the end leads
> to confusion.

i never claimed to be uri geller ;-)

i think we'll just have to agree to disagree.  Even if i convince nobody about this (which seems the most likely outcome ;-), i still think D looks to be a *very* promising language, and would love to make a living using it someday, superfluous literal castings and all.

regards,

Scott

"Scott Pigman" <scottpig1@attbi.com> wrote in message news:b0i46g$1u2v$1@digitaldaemon.com...
> basically my position is this:
>
> i can't imagine anyone ever saying, "gee, thank goodness the compiler forced me to write 'myFloat mf = (myFloat)0.0' because that really saved me from getting into trouble later on".  on the other hand, i can see lots of people saying, "Dammnit, i forgot to cast 0.0 to myFloat when i initialized my variable, arrggghhh, now where the hell was that..."  it won't be a big error surely, and not difficult to fix, but i don't see the point of forcing the programmer to have to do that.  i can see that it is indeed more conceptually pure to force the cast -- and you can work out the syntax of the cast yourselves, right now i don't care -- but i don't see any practical advantage to slavishly following the most conceptually pure paradigm in this instance.
I partially agree, I was quoteing the D spec, which defines how a typedef
works, and I dislike any special cases
if it works for a foo, it should work for a foo; literal or variable.

the more I think about it the more I come to the conclusion that numeric
typedefs should be the other way around
typedef int foo;
all int's are foo's not all foo's are ints
so you have to cast foo's to int's  (now literals don't need casts).
however that's a bit backwards it's like allowing you to declare a class
that is a super class to Object without being a super class to anything that
sub classes Object!

> > I still don't understand why you are using a typedef and not an alias ('alias' is almost directly equivilent to C 'typedef')
>
> yes, i'm quite sure i want typedef, not alias. i want D-style typedef for all the other things it does for us, even if i really must cast literals. in fact, i'm not convinced i would even want to see alias in the final language, seems to me like it would hide errors.

I find alias very useful

alias int delegate ( int, int ) myCallback;
class foo { int cbfunc( int a, int b ) { return a+b; } }
int func( myCallBack cb, int i ) { return cb( i ); }
foo myfoo = new foo();
int i = func( &myfoo.cbfunc );

if you typedef, then you have to cast;

adding the cast makes the code error prone, if you change the params then the compiler will not warn you because you have forced the type with a cast. if there was a way to declare a method in the class def as being of a type that is a typedef of its actual type then I would be more (but not totally) in favor of ditching alias. (again reversing the typedef rule solves this problem)

>
> > I use numeric typedef rarely, I don't see how typedef double money benifits the code in any way
>
> I have used, and intend to continue using, numeric typedefs.  in C, they help to me keep track of my intentions.  in D they'd enforce those intentions.  the example of "typedef double money" was a simplistic, contrived example, the kind usually used for discussions like this.  a simplistic, contrived example of how that would help me is:

> tyedef double money;
> typedef double velocity;
> void setVehicleVelocity(velocity v){...}
> money getAccountBalance(){...}
>
> setVehicleVelocity( getAccountBalance() ) // Error in D, legal in C

however

velocity getVehicleVelocity();
money calcInterestOnAccountBalance( double percent ){...}

cash = calcInterestOnAccountBalance( getVehicleVelocity() );
// is legal in D (all velocitys are doubles)
// which is one reason I think the rule should be reversed (literals being
the other) and I hate special cases

my one conclusions lead me to (most likely up the garden path and lost in
the woods)
to think the following should exist
`struct name : type;`  // same behaviour as typedef has now. all 'name' are
'type', cast needed to get from type to name
typedef type name; // opposite behaviour name is now a conceptual super
class of type. all type are name, cast need to get from name to type;
with a few more changes, you could have long as a modified typedef of int
(all ints are longs)
and even create a 128 bit number, or bignumber that was a typedef of long
(all longs are valid bigger numbers)
[too radical, ow well]


it would suit both our requirements if typedef was a just little looser,
typedef int foo;
typedef int bar;
int->foo (implicit) foo->int (implicit)
int->bar (implicit) bar->int (implicit)
foo<->bar (explicit)

typedef bar morebar;
would require a cast to assign to/from int;

and as I said earlier I loath casts, I would instead prefer a compiler
generated conv func that only allows a typedef of the underlying type, or
underlying type, to be used without warning/error.
bar b = bar( 1 ); // not cast(bar)1;
foo a = foo( b );

if something changed, i.e. `typedef float bar` you'd now get a warning/error can't make a foo from a bar (float)

>
> i think we'll just have to agree to disagree.  Even if i convince nobody about this (which seems the most likely outcome ;-), i still think D looks to be a *very* promising language, and would love to make a living using it someday, superfluous literal castings and all.
>
I'm sure Walter will be please to hear that,  not wanting to be too cynical but it seems the only way to make a living programming these days if in VB or gui generated Java/C# if its not rad, and you can't get a house trained monkey to program in it companies aren't interested.

lets end on a good note :) murthy's laws of technology, "if you make a system fool proof, only a fool would want to use it"

Scott Pigman wrote:
> basically my position is this:
> 
> i can't imagine anyone ever saying, "gee, thank goodness the compiler
> forced me to write 'myFloat mf = (myFloat)0.0' because that really saved
> me from getting into trouble later on".  on the other hand, i can see lots
> of people saying, "Dammnit, i forgot to cast 0.0 to myFloat when i
> initialized my variable, arrggghhh, now where the hell was that..."  it
> won't be a big error surely, and not difficult to fix, but i don't see the
> point of forcing the programmer to have to do that.  i can see that it is
> indeed more conceptually pure to force the cast -- and you can work out
> the syntax of the cast yourselves, right now i don't care -- but i don't
> see any practical advantage to slavishly following the most conceptually
> pure paradigm in this instance.
> 

Hm. Why don't you overload assignment operator so that when you assign a "float" or a "double" to "MyFloat", automatic conversion is done, cast implicitly? Either it is a legal assignment, which makes sense, or it is prohibited and by circumventing it with a cast you *always* make yourself a bad favor?
You will thus make sure it is legal to assign a float to these types, but you won't be able to assign "money" to a "velocity". A good style would be then to get rid of underlying types as soon as possible, and store everything as correct typedef-ed types.

BTW, i'll check whether it works like i expect it to. If it's still possible to assign a money var to velocity or vice versa after the assignment has been overloaded for their common underlying type, that'd actually be a design flaw.


> 
>>I still don't understand why you are using a typedef and not an alias
>>('alias' is almost directly equivilent to C 'typedef')
> 
> 
> yes, i'm quite sure i want typedef, not alias. i want D-style typedef for
> all the other things it does for us, even if i really must cast literals. in fact, i'm not convinced i would even want to see alias in the final
> language, seems to me like it would hide errors.
> 
> 
>>I use numeric typedef rarely, I don't see how typedef double money
>>benifits the code in any way
> 
> 
> I have used, and intend to continue using, numeric typedefs.  in C, they
> help to me keep track of my intentions.  in D they'd enforce those
> intentions.  the example of "typedef double money" was a simplistic,
> contrived example, the kind usually used for discussions like this.  a
> simplistic, contrived example of how that would help me is:
> 
> tyedef double money;
> typedef double velocity;
> void setVehicleVelocity(velocity v){...}
> money getAccountBalance(){...}
> 
> setVehicleVelocity( getAccountBalance() ) // Error in D, legal in C
> 
> 
>>if you look at it right you will see it is you that should bend and not
>>the spoon !
>>(even if the spoon is imperfect)
>>creating special cases leads to more special cases and in the end leads
>>to confusion.
> 
> 
> i never claimed to be uri geller ;-)
> 
> i think we'll just have to agree to disagree.  Even if i convince nobody
> about this (which seems the most likely outcome ;-), i still think D looks
> to be a *very* promising language, and would love to make a living using
> it someday, superfluous literal castings and all.
> 
> regards,
> 
> Scott
> 
> 

On Tue, 21 Jan 2003 19:51:50 +0100, Ilya Minkov wrote:


> Hm. Why don't you overload assignment operator so that when you assign a "float" or a "double" to "MyFloat", automatic conversion is done, cast

i'll look into it when i get a chance.  let me know what you discover.

-sp