www.digitalmars.com         C & C++   DMDScript  

D - Cast operators

reply "Matthew Wilson" <dmd synesis.com.au> writes:
Any chance of our getting away from the overused round braces in casts, and
adopt something less ambiguous, along the lines of the C++ casts?

It seems like a retrograde step.
Sep 17 2003
next sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 Any chance of our getting away from the overused round braces in casts,


and

 adopt something less ambiguous, along the lines of the C++ casts?

 It seems like a retrograde step.


Me I prefer function style cast... but I think that it should be the same as
for
template so that anyone could write it prefered cast as it is possible in
C++.

I would also like to have more cast as in C++ where we can explictly tell
the compiler which kind of casting we want to allows. In fact, I would even
like to have more cast than in C++. Some of the cast that I think of:

static_cast            // as in C++
reinterpret_cast    // low level bit reinterpret
const_cast            // as in C++ (we should add const support to D)
dynamic_cast        // base to derived

implicit_cast        // Allows if cast/conversion is implictly allowed
    without error (and disable any vendor specific warnings)

range_cast            // Ensure that the value fit in the target

same_layout_cast    // allowed if the layout is the same (x, y, z vs pt[3]
    or renamed member)

enum_cast        // Similar to range cast but only for enums

fit_cast            // fit to target range (any value lower than target
    min would be set to target min or -INF for floatting points,...)

...

and some more for plateform dependant cast, similar type cast (int to uint)
....

We should have one cast for each kind of casting that can be done...
and have cast if allowed on the current plateform vs defined exactly
by the language...

And I'd like to be able to add my owns...
Sep 17 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Philippe Mori" <philippe_mori hotmail.com> escreveu na mensagem
news:bk9q8l$27ov$1 digitaldaemon.com...

 Any chance of our getting away from the overused round braces in casts,


 and

 adopt something less ambiguous, along the lines of the C++ casts?

 It seems like a retrograde step.


 Me I prefer function style cast... but I think that it should be the same


as

 for
 template so that anyone could write it prefered cast as it is possible in
 C++.

 I would also like to have more cast as in C++ where we can explictly tell
 the compiler which kind of casting we want to allows. In fact, I would


even

 like to have more cast than in C++. Some of the cast that I think of:

 static_cast            // as in C++
 reinterpret_cast    // low level bit reinterpret
 const_cast            // as in C++ (we should add const support to D)
 dynamic_cast        // base to derived

 implicit_cast        // Allows if cast/conversion is implictly allowed
     without error (and disable any vendor specific warnings)

 range_cast            // Ensure that the value fit in the target

 same_layout_cast    // allowed if the layout is the same (x, y, z vs pt[3]
     or renamed member)

 enum_cast        // Similar to range cast but only for enums

 fit_cast            // fit to target range (any value lower than target
     min would be set to target min or -INF for floatting points,...)

 ...

 and some more for plateform dependant cast, similar type cast (int to


uint)

 ....

 We should have one cast for each kind of casting that can be done...
 and have cast if allowed on the current plateform vs defined exactly
 by the language...

 And I'd like to be able to add my owns...


IMO we should just keep the simple cast (using a "cast(type, value)" syntax
to reduce the parameters) and have all the other casts as templates. If we
do it this way we can keep the language clean of one hundred and one new
keywords and the syntax of templates will certainly improve (just imagine
dozens of developers frustrated with explicit instantiantion ;). Also
templates are the standard way to provide generic code (i.e. you would be
able to add your owns).



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
Sep 17 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
This gets my vote.  Keep the (cast) I vote.

One thing that does worry me, is that there are now a ton of keywords in D,
I realize that there all needed, but what are everyone elses thoughts on
this ?  Id like to keep it to as little as possible.

Charles
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bkaqnn$lbt$1 digitaldaemon.com...

 "Philippe Mori" <philippe_mori hotmail.com> escreveu na mensagem
 news:bk9q8l$27ov$1 digitaldaemon.com...

 Any chance of our getting away from the overused round braces in






casts,

 and

 adopt something less ambiguous, along the lines of the C++ casts?

 It seems like a retrograde step.


 Me I prefer function style cast... but I think that it should be the




same

 as

 for
 template so that anyone could write it prefered cast as it is possible




in

 C++.

 I would also like to have more cast as in C++ where we can explictly




tell

 the compiler which kind of casting we want to allows. In fact, I would


 even

 like to have more cast than in C++. Some of the cast that I think of:

 static_cast            // as in C++
 reinterpret_cast    // low level bit reinterpret
 const_cast            // as in C++ (we should add const support to D)
 dynamic_cast        // base to derived

 implicit_cast        // Allows if cast/conversion is implictly allowed
     without error (and disable any vendor specific warnings)

 range_cast            // Ensure that the value fit in the target

 same_layout_cast    // allowed if the layout is the same (x, y, z vs




pt[3]

     or renamed member)

 enum_cast        // Similar to range cast but only for enums

 fit_cast            // fit to target range (any value lower than target
     min would be set to target min or -INF for floatting points,...)

 ...

 and some more for plateform dependant cast, similar type cast (int to


 uint)

 ....

 We should have one cast for each kind of casting that can be done...
 and have cast if allowed on the current plateform vs defined exactly
 by the language...

 And I'd like to be able to add my owns...


 IMO we should just keep the simple cast (using a "cast(type, value)"


syntax

 to reduce the parameters) and have all the other casts as templates. If we
 do it this way we can keep the language clean of one hundred and one new
 keywords and the syntax of templates will certainly improve (just imagine
 dozens of developers frustrated with explicit instantiantion ;). Also
 templates are the standard way to provide generic code (i.e. you would be
 able to add your owns).



 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
Sep 17 2003
parent reply Felix <Felix_member pathlink.com> writes:
What about smthng like "variable.doCast(newType)" (standard method call). Yes,
will be more difficult for expressions, but not always:

(variable1+variable2/variable4).doCast(newType)

Me, one, I would preffer this to (newType) (Variable1+Variable2);
It is really necessar to have an operator-based syntax?


Also, other casts should be easier to add.

Yes, and please drop the "_" in function names. Just an innocent idea.



In article <bkav5t$rdo$1 digitaldaemon.com>, Charles Sanders says...

This gets my vote.  Keep the (cast) I vote.

One thing that does worry me, is that there are now a ton of keywords in D,
I realize that there all needed, but what are everyone elses thoughts on
this ?  Id like to keep it to as little as possible.

Charles
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bkaqnn$lbt$1 digitaldaemon.com...

 "Philippe Mori" <philippe_mori hotmail.com> escreveu na mensagem
 news:bk9q8l$27ov$1 digitaldaemon.com...

 Any chance of our getting away from the overused round braces in






casts,

 and

 adopt something less ambiguous, along the lines of the C++ casts?

 It seems like a retrograde step.


 Me I prefer function style cast... but I think that it should be the




same

 as

 for
 template so that anyone could write it prefered cast as it is possible




in

 C++.

 I would also like to have more cast as in C++ where we can explictly




tell

 the compiler which kind of casting we want to allows. In fact, I would


 even

 like to have more cast than in C++. Some of the cast that I think of:

 static_cast            // as in C++
 reinterpret_cast    // low level bit reinterpret
 const_cast            // as in C++ (we should add const support to D)
 dynamic_cast        // base to derived

 implicit_cast        // Allows if cast/conversion is implictly allowed
     without error (and disable any vendor specific warnings)

 range_cast            // Ensure that the value fit in the target

 same_layout_cast    // allowed if the layout is the same (x, y, z vs




pt[3]

     or renamed member)

 enum_cast        // Similar to range cast but only for enums

 fit_cast            // fit to target range (any value lower than target
     min would be set to target min or -INF for floatting points,...)

 ...

 and some more for plateform dependant cast, similar type cast (int to


 uint)

 ....

 We should have one cast for each kind of casting that can be done...
 and have cast if allowed on the current plateform vs defined exactly
 by the language...

 And I'd like to be able to add my owns...


 IMO we should just keep the simple cast (using a "cast(type, value)"


syntax

 to reduce the parameters) and have all the other casts as templates. If we
 do it this way we can keep the language clean of one hundred and one new
 keywords and the syntax of templates will certainly improve (just imagine
 dozens of developers frustrated with explicit instantiantion ;). Also
 templates are the standard way to provide generic code (i.e. you would be
 able to add your owns).



 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
Sep 17 2003
parent Felix <Felix_member pathlink.com> writes:
And this approach will be easier to manage in the "intellisense" (code
completion) based editors...


In article <bkbe0c$1gsc$1 digitaldaemon.com>, Felix says...

What about smthng like "variable.doCast(newType)" (standard method call). Yes,
will be more difficult for expressions, but not always:

(variable1+variable2/variable4).doCast(newType)

Me, one, I would preffer this to (newType) (Variable1+Variable2);
It is really necessar to have an operator-based syntax?


Also, other casts should be easier to add.

Yes, and please drop the "_" in function names. Just an innocent idea.



In article <bkav5t$rdo$1 digitaldaemon.com>, Charles Sanders says...

This gets my vote.  Keep the (cast) I vote.

One thing that does worry me, is that there are now a ton of keywords in D,
I realize that there all needed, but what are everyone elses thoughts on
this ?  Id like to keep it to as little as possible.

Charles
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bkaqnn$lbt$1 digitaldaemon.com...

 "Philippe Mori" <philippe_mori hotmail.com> escreveu na mensagem
 news:bk9q8l$27ov$1 digitaldaemon.com...

 Any chance of our getting away from the overused round braces in






casts,

 and

 adopt something less ambiguous, along the lines of the C++ casts?

 It seems like a retrograde step.


 Me I prefer function style cast... but I think that it should be the




same

 as

 for
 template so that anyone could write it prefered cast as it is possible




in

 C++.

 I would also like to have more cast as in C++ where we can explictly




tell

 the compiler which kind of casting we want to allows. In fact, I would


 even

 like to have more cast than in C++. Some of the cast that I think of:

 static_cast            // as in C++
 reinterpret_cast    // low level bit reinterpret
 const_cast            // as in C++ (we should add const support to D)
 dynamic_cast        // base to derived

 implicit_cast        // Allows if cast/conversion is implictly allowed
     without error (and disable any vendor specific warnings)

 range_cast            // Ensure that the value fit in the target

 same_layout_cast    // allowed if the layout is the same (x, y, z vs




pt[3]

     or renamed member)

 enum_cast        // Similar to range cast but only for enums

 fit_cast            // fit to target range (any value lower than target
     min would be set to target min or -INF for floatting points,...)

 ...

 and some more for plateform dependant cast, similar type cast (int to


 uint)

 ....

 We should have one cast for each kind of casting that can be done...
 and have cast if allowed on the current plateform vs defined exactly
 by the language...

 And I'd like to be able to add my owns...


 IMO we should just keep the simple cast (using a "cast(type, value)"


syntax

 to reduce the parameters) and have all the other casts as templates. If we
 do it this way we can keep the language clean of one hundred and one new
 keywords and the syntax of templates will certainly improve (just imagine
 dozens of developers frustrated with explicit instantiantion ;). Also
 templates are the standard way to provide generic code (i.e. you would be
 able to add your owns).



 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
Sep 17 2003
prev sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 We should have one cast for each kind of casting that can be done...
 and have cast if allowed on the current plateform vs defined exactly
 by the language...

 And I'd like to be able to add my owns...


 IMO we should just keep the simple cast (using a "cast(type, value)"


syntax

 to reduce the parameters) and have all the other casts as templates. If we
 do it this way we can keep the language clean of one hundred and one new
 keywords and the syntax of templates will certainly improve (just imagine
 dozens of developers frustrated with explicit instantiantion ;). Also
 templates are the standard way to provide generic code (i.e. you would be
 able to add your owns).


I have no problem with having other casts as template provide it is possible
to implement the desired cast... Often the compiler knows the information
while the programmer might or might not be able to knows it... I think that
in D we have more informations on type (like enum range) so we could more
easily define some of our cast... but some other might not be easily
possible
(is it possible to implement static_cast or dynamic_cast using only
templates
and existing cast by having specialisation for allowed and prohibited cases
and ensuring that prohibited cases does not compile?

So a minimum is needed to be able to do more... In C++, for example
it is hard to detect if a type is a class, an enum, a member pointer, a POD,
or to know if a class is abstract... without some support from the compiler.

In D, for example, we might want to know if a type is a typedef of another
one. Also we might want to be able to check layout compatibity of 2 types:

struct S { double x; double y; double z };
alias double [3] Coord;

S s;
Coord c = layout_cast(s);    // I want to compiler to validate that the
layout
    is compatible (and as you can see, specifying the target might not be
    necessary (but implicit instanciation would be required).

In fact, implicit instanciation is required for any user type as we do
not want to have to specify both the source and target type...

k = my_cast(TargetType, originalValue)
Sep 18 2003
prev sibling next sibling parent reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:bk9ln8$21k9$1 digitaldaemon.com...

 Any chance of our getting away from the overused round braces in casts,


and

 adopt something less ambiguous, along the lines of the C++ casts?

 It seems like a retrograde step.


How about a cast property?

double d = 3.14159;
printf("%d", d.cast); // outputs 3
Sep 17 2003
next sibling parent reply John Boucher <John_member pathlink.com> writes:
In article <bkaal5$2vat$1 digitaldaemon.com>, Andrew Edwards says...

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:bk9ln8$21k9$1 digitaldaemon.com...

 Any chance of our getting away from the overused round braces in casts,


and

 adopt something less ambiguous, along the lines of the C++ casts?

 It seems like a retrograde step.


How about a cast property?

double d = 3.14159;
printf("%d", d.cast); // outputs 3


Well, you'd still need to tell it what to cast to wouldn't you?:
d.cast(int)
so what's the difference?

And it would be better to have:
d.toString(formatstring)
d.toInt
d.toUInt
etc. and all the baggage that follows.

John Boucher
The King had Humpty pushed.
Sep 17 2003
parent reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
"John Boucher" <John_member pathlink.com> wrote in message
news:bkacc2$ar$1 digitaldaemon.com...

 Well, you'd still need to tell it what to cast to wouldn't you?:
 d.cast(int)
 so what's the difference?


not necessarily!

format specifiers provides the format of the intended input (in this case
int). Upon seeing the cast property, printf should automatically convert
d.cast to the expected input.

likewise,

char [] dstr;
char[30] cstr = "Is this even possible?";
dstr = cstr; // error
dstr = cstr.cast; // ok

the compiler already knows what's expected and will automatally bark at
improperly typed inputs or rvalues. Upon seeing cstr.cast however, it should
treat cstr as if it were a dynamic string.

Andrew
Sep 17 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 format specifiers provides the format of the intended input (in this case
 int). Upon seeing the cast property, printf should automatically convert
 d.cast to the expected input.


Automatic casting won't works with printf since the format string
may not be known to the compiler... and the compiler assumes
that the type is correct!


 likewise,

 char [] dstr;
 char[30] cstr = "Is this even possible?";
 dstr = cstr; // error
 dstr = cstr.cast; // ok

 the compiler already knows what's expected and will automatally bark at
 improperly typed inputs or rvalues. Upon seeing cstr.cast however, it


should

 treat cstr as if it were a dynamic string.


For conversion, I do like the idea... And it would allows conversion
that are normally explicit to be done implictly... So something like
that should even be possible:

int i;
bool b = (1 + i).cast;

double d;
int j = (3.453 * d).cast;
int k = d.cast;

uint m;
if (m == j.cast)    // convert j to unsigned for comparison
{
}
Sep 18 2003
prev sibling parent reply "Dario" <supdar yahoo.com> writes:
I would prefer something like:
.    class A {}
.    class B:A {void func(){}}
.    A b = new B;
.    B.cast(b).func();
Rather than having to write:
.    (cast(B) b).func();
Isn't the former easier to read?

Consider more complex code like the following:
.    ((CK) ((CA) list[i]).kid).func();
That becomes:
.    CK.cast(CA.cast(list[i]).kid).func();


Andrew Edwards:

 How about a cast property?
 double d = 3.14159;
 printf("%d", d.cast); // outputs 3


Matthew Wilson:

 Any chance of our getting away from the overused round braces in casts,


and

 adopt something less ambiguous, along the lines of the C++ casts?
 It seems like a retrograde step.
Sep 23 2003
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bkq9th$17fn$1 digitaldaemon.com>, Dario says...

.    B.cast(b).func();


Yes! finally something that makes sense!
We have been waiting for this for decades.

? b.castTo(B).func() ?

Ant
Sep 23 2003
next sibling parent reply Benji Smith <dlanguage xxagg.com> writes:
.    B.cast(b).func();




I hate this one. It looks like your doing something to a "B" object.
But you aren't. You're doing something to a "b" object. This syntax is
very deceptive.


b.castTo(B).func()


This one, I like. A lot.

--Benji
Sep 23 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
.    B.cast(b).func();




 I hate this one. It looks like your doing something to a "B" object.
 But you aren't. You're doing something to a "b" object. This syntax is
 very deceptive.


b.castTo(B).func()


 This one, I like. A lot.


Idem for me. I'd like the second syntax... and it is far better than the
suggested on since it does not require too much parenthesis that we
must look carefully...

In fact, we just have to look inside the () after the predefined
castTo method to know what we are casting... and in complex
expression, this is surely easier to read than prefix casting.
Sep 23 2003
prev sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
 In article <bkq9th$17fn$1 digitaldaemon.com>, Dario says...

 I would prefer something like:
    class A {}
    class B:A {void func(){}}
    A b = new B;
    B.cast(b).func();




I stared that for a moment and thought that you surely made a typo there
and actually meant to write:

b.cast(B).func();

Which kind of makes sense.

(similarly as Ant suggested:)

In article <bkqaoi$18hk$1 digitaldaemon.com>, Ant wrote:

 Yes! finally something that makes sense!
 We have been waiting for this for decades.

 ? b.castTo(B).func() ?


How about:

cast(B, b).func()

cast(B: b).func();

cast(B; b).func(); // Syntax a bit similar to foreach(); emphasizes that
                   // cast is not just any function

or even

cast(b, B).func();
cast(b to B).func();
cast(b as B).func();
cast(b -> B).func(); // too bad -> already has a meaning
cast(b: B).func();
cast(B b).func();

cast(B) b.func(); // Java style, huh?

(cast(B) b).func(); // What we have now. Cluttered.

But for what it's worth, D isn't trying to be Java, so well-written
programs contain very few casts anyway and those that remain deserve to
stand out. Right?

-Antti
Sep 23 2003
next sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 Yes! finally something that makes sense!
 We have been waiting for this for decades.

 ? b.castTo(B).func() ?


 How about:

 cast(B, b).func()

 cast(B: b).func();

 cast(B; b).func(); // Syntax a bit similar to foreach(); emphasizes that
                    // cast is not just any function

 or even

 cast(b, B).func();
 cast(b to B).func();
 cast(b as B).func();
 cast(b -> B).func(); // too bad -> already has a meaning
 cast(b: B).func();
 cast(B b).func();


In some case like casting the result of a function,
I like better

    f().castTo(double)

than

    cast(double, f())

I'm not sure about the last suggestion but I think that even
if it would be possible to uses a syntax without separator
it is better to have a separtator (and in my opinion it should be ,)
since if both the type and the expression are complex, it is
easier to see where one ends and the other start.

Also, I like using , as the separator as this is consistent with
template...


 cast(B) b.func(); // Java style, huh?


With this syntac as in C++, it is hard to knows where the cast
end if the expression is a bit complex and we need extra ().
For example, if we want to cast function result...


 (cast(B) b).func(); // What we have now. Cluttered.

 But for what it's worth, D isn't trying to be Java, so well-written
 programs contain very few casts anyway and those that remain deserve to
 stand out. Right?


Cast should be easy to spot and should be easy to understand
without needing to count ()...

Also the selected syntax should be compatible with templates
and should be extendable to user defined cast...

If the object.cast syntax is used, then we might want to be able
to define our cast to a given type :

class C {
    operator castTo(D) { return ... }
    operator castTo(E) { return ... }

    template (T)
    operator castTo(T) { return member.castTo(T); }
}

OTHO, if we uses a syntax like cast(B, b), we should be
able to define our owns casting functions that works the
same way:

// Cast and if not possible returns default (just an example)
template (T, U)
T cast_or_default(U u)
{
    try {
        return cast(T) u;
    } catch(...) {
        return T.init;
    }
}
Sep 23 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Philippe Mori" <philippe_mori hotmail.com> wrote in message
news:bkqfd3$1fkc$1 digitaldaemon.com...

 If the object.cast syntax is used, then we might want to be able
 to define our cast to a given type :

 class C {
     operator castTo(D) { return ... }
     operator castTo(E) { return ... }

     template (T)
     operator castTo(T) { return member.castTo(T); }
 }


Sure!  But we would need some official way to accept a _type_ as a function
parameter!


 OTHO, if we uses a syntax like cast(B, b), we should be
 able to define our owns casting functions that works the
 same way:


I really don't like this syntax;  it's confusing which comes first, the type
or the rvalue.

Sean
Sep 24 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 If the object.cast syntax is used, then we might want to be able
 to define our cast to a given type :

 class C {
     operator castTo(D) { return ... }
     operator castTo(E) { return ... }

     template (T)
     operator castTo(T) { return member.castTo(T); }
 }


 Sure!  But we would need some official way to accept a _type_ as a


function

 parameter!


I think this would surely be a good thing to accept a type as a function
parameter and it would be interesting for metaprogramming. Here a
simple example for a factory:

    class Base { }
    class Der1 : Base { }
    class Der2 : Base { }
    class Der3 : Base { }

    Base CreateObject(type t, int arg1, int arg2)
    {
        return new t(arg1, arg2);
    }

    Base a = CreateObject(Der1, 5, 3);
    Base b = CreateObject(typeof(a), 6, 4);

But for casting purpose this is not strictly necessary since in
C++ we have conversion operator but we do not have
type function parameters:

    class C {    // C++ sample
    public:
        // the typename give the operator name.
        // for complex type a typedef might be required.
        operator double() const { return 23.4; }

        // template is even supported...
        // Here we allows any supported conversion from a member
        template <typename T>
        operator T { return member; }

        M member;
    };

So IMHO, we should choose the syntax mainly according to the
following rules:

- easy to uses and to read.
- consistent with the language (template, predefine members syntax,...)


 OTHO, if we uses a syntax like cast(B, b), we should be
 able to define our owns casting functions that works the
 same way:


 I really don't like this syntax;  it's confusing which comes first, the


type

 or the rvalue.


I see... and with Ant sample, I see why this syntax is not elegant for
complex expression in which there are multiples casts...


 Sean
Sep 24 2003
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Philippe Mori wrote:

 If the object.cast syntax is used, then we might want to be able
 to define our cast to a given type :
 
 class C {
     operator castTo(D) { return ... }
     operator castTo(E) { return ... }
 
     template (T)
     operator castTo(T) { return member.castTo(T); }
 }


This introduces the possibility to mess with some assumptions we have 
about casting.

For example, it should be possible to cast the object that is returned 
by castTo back to the original type. This would have to be explicitly 
supported by the programmer the returned object.

I'm not sure wether this is necessarily such a bad thing, though. After 
all, operator overloads can always cause stuff like this. On the other 
hand, this seems like it could get complicated pretty quickly. Imagine 
the following case:

class A
{
	B b;
	C c;

	operator castTo(B) { return b; }
	operator castTo(C) { return c; }
};

A a;

//This works
a.castTo(C);

//And this works;
a.castTo(B);

//Then this should work as well
a.castTo(B).castTo(C)


So B would not only have to know how it can be casted back to A, but it 
should also know how to cast to the "sister" interface C.

Note that this concept is pretty similar to the way Microsoft's COM and 
the QueryInterface method works. MS uses this quite a bit to implement 
interfaces using aggregated objects. Does anyone have sufficient 
experience with this to offer an opinion on wether it is worth the trouble?

Hauke
Sep 24 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 If the object.cast syntax is used, then we might want to be able
 to define our cast to a given type :

 class C {
     operator castTo(D) { return ... }
     operator castTo(E) { return ... }

     template (T)
     operator castTo(T) { return member.castTo(T); }
 }


 This introduces the possibility to mess with some assumptions we have
 about casting.


In C++, we can define our owns conversion functions... The biggest
problem we have in C++ are:

- unintended conversion (a conversion that is not always desirable),
like the conversion from some string classes to const char * or some
automatic pointers classes to the pointer.


- ambiguities when a class allows conversion to a class that accept
original type in one of its constructor:

    class A;
    class B {
    public:
        operator A() const;
    };

    class A {
    public:
        A (B const &b) { }
    };


 For example, it should be possible to cast the object that is returned
 by castTo back to the original type. This would have to be explicitly
 supported by the programmer the returned object.


Enven in the language not all casts allows to returns to the original
exactly:

    double d = 1.2;
    int i = cast(int) d;
    double d2 = cast(double) i;

    d will be different than d2 (but in that case, the cast is allowed).


 I'm not sure wether this is necessarily such a bad thing, though. After
 all, operator overloads can always cause stuff like this. On the other
 hand, this seems like it could get complicated pretty quickly. Imagine
 the following case:

 class A
 {
 B b;
 C c;

 operator castTo(B) { return b; }
 operator castTo(C) { return c; }
 };

 A a;

 //This works
 a.castTo(C);

 //And this works;
 a.castTo(B);

 //Then this should work as well
 a.castTo(B).castTo(C)


 So B would not only have to know how it can be casted back to A, but it
 should also know how to cast to the "sister" interface C.

 Note that this concept is pretty similar to the way Microsoft's COM and
 the QueryInterface method works. MS uses this quite a bit to implement
 interfaces using aggregated objects. Does anyone have sufficient
 experience with this to offer an opinion on wether it is worth the


trouble?

For COM stuff, we need to be able to delegate to the outer object. That
is the subobjects b and c need to be able to get the this pointer of the A
object that contains them.

IMO, the cleanest way to handled that would be to support local classes
that have access to the outer class.

In such a case, COM compatible casting would be easy to implement
provide that cast operator have priority over predefined cast (to ensure
that casting to IUnknown or I2 in the example below will return the proper
interface).

Also for COM programming, with need 2 casting operators: One that
do the casting for a given object and one that forward casting to the
outer object (otherwise, we would have infinite loops or case where
the identity won't be respected (i.e. for I2 we always want to returns
either A or C object - not sometime ones and other times the other-
and that without depending on the source of the cast).

class A : I1, I2 {
    local class B : I2 {
        template (T) operator castTo(T) { return outer.castTo(T); }
    } b;

    local class C : I3 {
        template (T) operator castTo(T) { return outer.castTo(T); }
    } c;

    operator castTo(I2) { return b.internal_castTo(I2) }
    operator castTo(I3) { return c.internal_castTo(I3) }
}

So to implement COM interface casting, which might be great for
COM programming, I think we need some extra casting operators.
In essence, we need an operator that is called by QueryInterface
for each subobject. That operator will then forward to the outer
object which will the uses our internal casting.

Also we need blind query... but that we be done with a template
and verifying the result of the cast....


 Hauke
Sep 24 2003
prev sibling next sibling parent Ant <Ant_member pathlink.com> writes:
In article <slrnbn1eo0.dbp.jsykari pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?=
says...

(similarly as Ant suggested:)

In article <bkqaoi$18hk$1 digitaldaemon.com>, Ant wrote:

 Yes! finally something that makes sense!
 We have been waiting for this for decades.

 ? b.castTo(B).func() ?


How about:

cast(B, b).func()


you mean:
cast(cast(list[i], B).kid), CK).func()
nahhh... same old thing...

list[i].castTo(CA).kid.castTo(CK).func()
is still better!

Ant
Sep 23 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Nah, Ant's form is better.  Clearer.

b.cast(B).func();

Works even if B is a complicated typespec;  easy to parse;  easy to read.
Self-documenting.

myObjectPtr[n].cast(myFoo*[])[i]->DoFooStuff("foo baby".cast(wchar[]));

This is good.  I like it better than the cast D has now.

DMD still hasn't gotten rid of C's typecast!  I thought the D spec doesn't
support C typecasts?

Sean

"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbn1eo0.dbp.jsykari pulu.hut.fi...

 In article <bkq9th$17fn$1 digitaldaemon.com>, Dario says...

 I would prefer something like:
    class A {}
    class B:A {void func(){}}
    A b = new B;
    B.cast(b).func();




 I stared that for a moment and thought that you surely made a typo there
 and actually meant to write:

 b.cast(B).func();

 Which kind of makes sense.

 (similarly as Ant suggested:)

 In article <bkqaoi$18hk$1 digitaldaemon.com>, Ant wrote:

 Yes! finally something that makes sense!
 We have been waiting for this for decades.

 ? b.castTo(B).func() ?


 How about:

 cast(B, b).func()

 cast(B: b).func();

 cast(B; b).func(); // Syntax a bit similar to foreach(); emphasizes that
                    // cast is not just any function

 or even

 cast(b, B).func();
 cast(b to B).func();
 cast(b as B).func();
 cast(b -> B).func(); // too bad -> already has a meaning
 cast(b: B).func();
 cast(B b).func();

 cast(B) b.func(); // Java style, huh?

 (cast(B) b).func(); // What we have now. Cluttered.

 But for what it's worth, D isn't trying to be Java, so well-written
 programs contain very few casts anyway and those that remain deserve to
 stand out. Right?

 -Antti
Sep 24 2003
parent Felix <Felix_member pathlink.com> writes:
I like this kind of cast. I. e. variable.doCast(newType) etc...



In article <bkrjpa$vg$1 digitaldaemon.com>, Sean L. Palmer says...

Nah, Ant's form is better.  Clearer.

b.cast(B).func();

Works even if B is a complicated typespec;  easy to parse;  easy to read.
Self-documenting.

myObjectPtr[n].cast(myFoo*[])[i]->DoFooStuff("foo baby".cast(wchar[]));

This is good.  I like it better than the cast D has now.

DMD still hasn't gotten rid of C's typecast!  I thought the D spec doesn't
support C typecasts?

Sean

"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbn1eo0.dbp.jsykari pulu.hut.fi...

 In article <bkq9th$17fn$1 digitaldaemon.com>, Dario says...

 I would prefer something like:
    class A {}
    class B:A {void func(){}}
    A b = new B;
    B.cast(b).func();




 I stared that for a moment and thought that you surely made a typo there
 and actually meant to write:

 b.cast(B).func();

 Which kind of makes sense.

 (similarly as Ant suggested:)

 In article <bkqaoi$18hk$1 digitaldaemon.com>, Ant wrote:

 Yes! finally something that makes sense!
 We have been waiting for this for decades.

 ? b.castTo(B).func() ?


 How about:

 cast(B, b).func()

 cast(B: b).func();

 cast(B; b).func(); // Syntax a bit similar to foreach(); emphasizes that
                    // cast is not just any function

 or even

 cast(b, B).func();
 cast(b to B).func();
 cast(b as B).func();
 cast(b -> B).func(); // too bad -> already has a meaning
 cast(b: B).func();
 cast(B b).func();

 cast(B) b.func(); // Java style, huh?

 (cast(B) b).func(); // What we have now. Cluttered.

 But for what it's worth, D isn't trying to be Java, so well-written
 programs contain very few casts anyway and those that remain deserve to
 stand out. Right?

 -Antti
Sep 24 2003
prev sibling parent reply "Dario" <supdar yahoo.com> writes:
Antti Sykäri:

 I stared that for a moment and thought that you surely made a typo there
 and actually meant to write:
 b.cast(B).func();
 Which kind of makes sense.


That wan't a typo! ;-)
I thought of that because Ant's version is complicated to parse
(function don't get types as parameters).
Anyway I am convinced that Ant's version is more intuitive too.

I noticed that there are no comments from Walter...
Walter, what do you think? You aren't going to keep the
prefix cast, are you?
Sep 25 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Dario" <supdar yahoo.com> wrote in message
news:bkvsqs$26e9$1 digitaldaemon.com...

 Antti Sykäri:

 I stared that for a moment and thought that you surely made a typo there
 and actually meant to write:
 b.cast(B).func();
 Which kind of makes sense.


 That wan't a typo! ;-)
 I thought of that because Ant's version is complicated to parse
 (function don't get types as parameters).
 Anyway I am convinced that Ant's version is more intuitive too.

 I noticed that there are no comments from Walter...
 Walter, what do you think? You aren't going to keep the
 prefix cast, are you?


The postfix cast does look good, but I don't see it has much advantage over
the prefix cast.
Dec 02 2003
next sibling parent reply "Matthew Wilson" <matthew.hat stlsoft.dot.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bqjfni$nc0$1 digitaldaemon.com...

 "Dario" <supdar yahoo.com> wrote in message
 news:bkvsqs$26e9$1 digitaldaemon.com...

 Antti Sykäri:

 I stared that for a moment and thought that you surely made a typo






there

 and actually meant to write:
 b.cast(B).func();
 Which kind of makes sense.


 That wan't a typo! ;-)
 I thought of that because Ant's version is complicated to parse
 (function don't get types as parameters).
 Anyway I am convinced that Ant's version is more intuitive too.

 I noticed that there are no comments from Walter...
 Walter, what do you think? You aren't going to keep the
 prefix cast, are you?


 The postfix cast does look good, but I don't see it has much advantage


over

 the prefix cast.


Looks too much like a function call to me. What's wrong with cast(B, b) ?

I agree that the prefix cast must die.
Dec 02 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew.hat stlsoft.dot.org> wrote in message
news:bqjrg3$19kg$1 digitaldaemon.com...

 I noticed that there are no comments from Walter...
 Walter, what do you think? You aren't going to keep the
 prefix cast, are you?


 The postfix cast does look good, but I don't see it has much advantage


 over

 the prefix cast.


 Looks too much like a function call to me. What's wrong with cast(B, b) ?

 I agree that the prefix cast must die.


Because it is not immediately obvious which of cast's two parameters are the
thing to be casted, and which is the type to cast to.

b.cast(B) is much clearer in this regard, which is why everybody was
promoting it back then.  Apparently Walter is just getting to that
discussion.  ;)

B.cast(b) might work.  Either way, it might need to have some extra
parenthesis, like this:

(new b).cast(B)

(B*).cast(b);

I wish a good cast syntax would be chosen, but picking one is not easy, it's
all bad.

Sean
Dec 03 2003
next sibling parent reply "Matthew Wilson" <matthew.hat stlsoft.dot.org> writes:
 I noticed that there are no comments from Walter...
 Walter, what do you think? You aren't going to keep the
 prefix cast, are you?


 The postfix cast does look good, but I don't see it has much advantage


 over

 the prefix cast.


 Looks too much like a function call to me. What's wrong with cast(B, b)




?

 I agree that the prefix cast must die.


 Because it is not immediately obvious which of cast's two parameters are


the

 thing to be casted, and which is the type to cast to.

 b.cast(B) is much clearer in this regard, which is why everybody was
 promoting it back then.  Apparently Walter is just getting to that
 discussion.  ;)

 B.cast(b) might work.  Either way, it might need to have some extra
 parenthesis, like this:

 (new b).cast(B)

 (B*).cast(b);

 I wish a good cast syntax would be chosen, but picking one is not easy,


it's

 all bad.


cast<B>(b) ??
Dec 03 2003
parent Georg Wrede <Georg_member pathlink.com> writes:
     a.b.cast(Foo).c.d.cast(Bar).e.f
 is easier to read than:
     (cast(Bar)((cast(Foo)(a.b)).c.d)).e.f



 Bar myBar = a.b;
 Foo myFoo = myBar.c.d;
 myFoo.e.f;


An idea, what if we could write

mything = cast(foo)g.cast(bar)h.i.j.cast(baz)k;

Then the top example above, if I've understood it correctly,
becomes

a.cast(Foo)b.c.cast(Bar)d.e.f

If we have to do a hairy mix of casts and methods it
would still be legible:

a.cast(I)b.factMethod(cast(J)c).method(cast(K)d,cast(L)e)
Dec 03 2003
prev sibling next sibling parent davepermen <davepermen_member pathlink.com> writes:
I wish a good cast syntax would be chosen, but picking one is not easy, it's
all bad.

Sean


we just need a good template syntax, and this problem is no problem anymore..

just as static_cast, dynamic_cast, and all behave simply as templated functions
in C++. (and that way you could introduce new casts... like com_cast, or
any_cast, or lexical_cast..)
Dec 03 2003
prev sibling parent Felix <Felix_member pathlink.com> writes:
Me too, I vote for diff. cast function. As for me, concerning the postfixed
cast, I simply think that a.castTo(B) is best of all...


In article <bqkcal$2365$1 digitaldaemon.com>, Sean L. Palmer says...

"Matthew Wilson" <matthew.hat stlsoft.dot.org> wrote in message
news:bqjrg3$19kg$1 digitaldaemon.com...

 I noticed that there are no comments from Walter...
 Walter, what do you think? You aren't going to keep the
 prefix cast, are you?


 The postfix cast does look good, but I don't see it has much advantage


 over

 the prefix cast.


 Looks too much like a function call to me. What's wrong with cast(B, b) ?

 I agree that the prefix cast must die.


Because it is not immediately obvious which of cast's two parameters are the
thing to be casted, and which is the type to cast to.

b.cast(B) is much clearer in this regard, which is why everybody was
promoting it back then.  Apparently Walter is just getting to that
discussion.  ;)

B.cast(b) might work.  Either way, it might need to have some extra
parenthesis, like this:

(new b).cast(B)

(B*).cast(b);

I wish a good cast syntax would be chosen, but picking one is not easy, it's
all bad.

Sean
Dec 03 2003
prev sibling next sibling parent Berin Loritsch <bloritsch d-haven.org> writes:
Matthew Wilson wrote:


 
 Looks too much like a function call to me. What's wrong with cast(B, b) ?
 
 I agree that the prefix cast must die.


Umm, here is a simple, but maybe radical idea... why have explicit casts at all?

For example, what is wrong with this?

CrisisManager crisis = serviceLocater.lookup(CrisisManager.ROLE);
SubjectManager subject = serviceLocator.lookup(SubjectManager.ROLE);

In both cases, it is perfectly clear what end type is desired.  The cast from
an object to the end type is all that is needed--which the compiler can take
care of.

For those times where there may be ambiguity, then we might have to work
something out.  Either always force the use of a holder variable for the cast
to work, or use an "as" keyword like this:

printf("Common string embedding %s", myCrisis.getTitle() as char*);

That way you avoid unecessary prefix casting or postfix casting looking like
a method call.
Dec 03 2003
prev sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bqjrg3$19kg$1 digitaldaemon.com>, Matthew Wilson wrote:

 "Walter" <walter digitalmars.com> wrote in message
 news:bqjfni$nc0$1 digitaldaemon.com...

 "Dario" <supdar yahoo.com> wrote in message
 news:bkvsqs$26e9$1 digitaldaemon.com...

 Antti Sykäri:

 I stared that for a moment and thought that you surely made a typo






 there

 and actually meant to write:
 b.cast(B).func();
 Which kind of makes sense.


 That wan't a typo! ;-)
 I thought of that because Ant's version is complicated to parse
 (function don't get types as parameters).
 Anyway I am convinced that Ant's version is more intuitive too.

 I noticed that there are no comments from Walter...
 Walter, what do you think? You aren't going to keep the
 prefix cast, are you?


 The postfix cast does look good, but I don't see it has much
 advantage over the prefix cast.


 
 Looks too much like a function call to me. What's wrong with cast(B, b) ?


Looks like a function call? ;-)

But seriously, it does!

-Antti
Dec 03 2003
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 The postfix cast does look good, but I don't see it has much advantage over
 the prefix cast.


I like the idea of postfix cast because it makes long chained 
expressions easier to read.  IMHO, this:
	a.b.cast(Foo).c.d.cast(Bar).e.f
is easier to read than:
	(cast(Bar)((cast(Foo)(a.b)).c.d)).e.f
Dec 03 2003
next sibling parent Berin Loritsch <bloritsch d-haven.org> writes:
Russ Lewis wrote:


 Walter wrote:
 

 The postfix cast does look good, but I don't see it has much advantage 
 over
 the prefix cast.


 
 
 I like the idea of postfix cast because it makes long chained 
 expressions easier to read.  IMHO, this:
     a.b.cast(Foo).c.d.cast(Bar).e.f
 is easier to read than:
     (cast(Bar)((cast(Foo)(a.b)).c.d)).e.f
 


Honestly, I don't like having to type cast() at all.  Although I agree
that the example you had would look equally ugly in Java code:

((Bar)((Foo)a).b).c.d.e.f

However, such a construct is not common IMO.  At most there would be
only one cast needed:

((Foo)mycollection.get("Foo")).doSomething();

And IMO, it would be even better to do something like this:

Foo myfoo = mycollection.get("Foo");
myfoo.doSomething();

It is more clear that is what is going on, as opposed to placing the
two method calls on the same line--in such a way that would fool sloc
counters....
Dec 03 2003
prev sibling next sibling parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Russ Lewis wrote:


 Walter wrote:
 

 The postfix cast does look good, but I don't see it has much advantage 
 over
 the prefix cast.


 
 
 I like the idea of postfix cast because it makes long chained 
 expressions easier to read.  IMHO, this:
     a.b.cast(Foo).c.d.cast(Bar).e.f
 is easier to read than:
     (cast(Bar)((cast(Foo)(a.b)).c.d)).e.f
 


How about this instead:

Bar myBar = a.b;
Foo myFoo = myBar.c.d;
myFoo.e.f;

It forces you to break up the expression into something less confusing
and ends up being easier to read.

Of course I would prefer to use "as" instead of "cast" if we had to
clarify things.

a.b.as(Foo).c.b.as(Bar).e.f;

I just have trouble envisioning this need....
Dec 03 2003
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Berin Loritsch wrote:

 Russ Lewis wrote:
 

 Walter wrote:


 The postfix cast does look good, but I don't see it has much 
 advantage over
 the prefix cast.




 I like the idea of postfix cast because it makes long chained 
 expressions easier to read.  IMHO, this:
     a.b.cast(Foo).c.d.cast(Bar).e.f
 is easier to read than:
     (cast(Bar)((cast(Foo)(a.b)).c.d)).e.f


 
 How about this instead:
 
 Bar myBar = a.b;
 Foo myFoo = myBar.c.d;
 myFoo.e.f;


I use either one-line or multi-line solutions, based on which is more 
readable.  In some scenarios, one is better; in others, the other.

However, IMHO, prefix cast almost *forces* you to use multiple lines. 
That means that, sometimes, the code is less readable than it would have 
been if the language had been more flexible.


 It forces you to break up the expression into something less confusing
 and ends up being easier to read.
 
 Of course I would prefer to use "as" instead of "cast" if we had to
 clarify things.
 
 a.b.as(Foo).c.b.as(Bar).e.f;
 
 I just have trouble envisioning this need....


I have run across it more than once.  Two casts is rare, but having one 
cast, followed by some member accesses or method calls, is not unusual.
Dec 03 2003
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Berin Loritsch wrote:

 I like the idea of postfix cast because it makes long chained 
 expressions easier to read.  IMHO, this:
     a.b.cast(Foo).c.d.cast(Bar).e.f
 is easier to read than:
     (cast(Bar)((cast(Foo)(a.b)).c.d)).e.f


 
 How about this instead:
 
 Bar myBar = a.b;
 Foo myFoo = myBar.c.d;
 myFoo.e.f;
 
 It forces you to break up the expression into something less confusing
 and ends up being easier to read.


That might be true for some situations, but this has the potential to 
get annoying in others. For example, you cannot take the return value of 
one function, cast it and directly pass it into another. Having to use 
temporaries all the time can be a bad thing. And it can also make code 
less readable by adding lots of unnecessary lines of code and locals 
that do not really serve a purpose.

Also, I suspect (though I'm not sure) that this could make optimizing 
(particularly inlining) harder for the compiler. At the very least it 
will increase the compile time, because there are more local vars to 
consider.

Also, such an implicit casting would water down D's strong type 
checking, which is a Bad Thing, IMHO.

The postfix cast gets my vote!

Hauke
Dec 03 2003
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Hauke Duden wrote:

 Berin Loritsch wrote:
 

 I like the idea of postfix cast because it makes long chained 
 expressions easier to read.  IMHO, this:
     a.b.cast(Foo).c.d.cast(Bar).e.f
 is easier to read than:
     (cast(Bar)((cast(Foo)(a.b)).c.d)).e.f


 How about this instead:

 Bar myBar = a.b;
 Foo myFoo = myBar.c.d;
 myFoo.e.f;

 It forces you to break up the expression into something less confusing
 and ends up being easier to read.


 
 
 That might be true for some situations, but this has the potential to 
 get annoying in others. For example, you cannot take the return value of 
 one function, cast it and directly pass it into another. Having to use 
 temporaries all the time can be a bad thing. And it can also make code 
 less readable by adding lots of unnecessary lines of code and locals 
 that do not really serve a purpose.


Not necessarily.  As long as there is no ambiguity, the implicit cast should
continue to work:

interface Bar {}

int foo(Bar baz)
{
     return 1;
}

class SubClass : Bar {}

// .... in client code later on

foo( new SubClass() );

// or

foo( getInstance() ); // returning SubClass or other impl of Bar


 
 Also, I suspect (though I'm not sure) that this could make optimizing 
 (particularly inlining) harder for the compiler. At the very least it 
 will increase the compile time, because there are more local vars to 
 consider.


If that is the case, the compiler is not very good.


 Also, such an implicit casting would water down D's strong type 
 checking, which is a Bad Thing, IMHO.
 
 The postfix cast gets my vote!


I don't think so.  We are not talking about operator overloading here
which waters it down for real.

What we are talking about is leveraging the strong typing so that you
can never *upcast*.

One danger in allowing upcasts (i.e. casting to an interface/type that
is higher in the heirarchy) is that you are no longer working with those
types.  This is the source of many ClassCastExceptions in Java.  Another
issue has to do with hijacking responsibility.

For instance, if I have a component that I give a lookup service to,
I want to be able to ensure no other component can hijack that lookup service.
I have some Java code that demonstrates that issue--which can easily be
thwarted with proxies.

The only upcast that should ever work is one from the generic object type
to an Interface.  Once there is a definite type, no more upcasting.

Then again, this might fall under the half-baked idea column.  This comes
from my loathing to type the cast all the time when my intention is only
to use the interface as is.  I would be more than willing to use generics,
but there is no way to use generics when the return type is different depending
on the lookup key.
Dec 03 2003
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Berin Loritsch wrote:

 Not necessarily.  As long as there is no ambiguity, the implicit cast 
 should
 continue to work:
 
 interface Bar {}
 
 int foo(Bar baz)
 {
     return 1;
 }
 
 class SubClass : Bar {}
 
 // .... in client code later on
 
 foo( new SubClass() );
 
 // or
 
 foo( getInstance() ); // returning SubClass or other impl of Bar


I think there is some kind of misunderstanding.

If getInstance() returns a sub class of Bar, then there will be no cast 
necessary, because the returned object already is of the correct type.


 What we are talking about is leveraging the strong typing so that you
 can never *upcast*.


Ah. I think I understand what you want. You just want to remove casting 
altogether, thus only allowing what you call "implicit casts", i.e. 
casts to a base type?

Wouldn't work. For example, sometimes you just have to pass a sub class 
thorugh a program component that only knows the base class and cast it 
back up to the original type afterwards.

Btw, what *I* thought you meant is to use temporary variables to perform 
a real cast. I.e. allow assigning any type to a local variable when that 
variable is constructed:

Bar getBar();
void setFoo(Foo foo);

Foo foo=getBar();

but not

setFoo(getBar());

for unrelated types Foo and Bar.

THAT would water down D's type system!


 The only upcast that should ever work is one from the generic object type
 to an Interface.  Once there is a definite type, no more upcasting.


That would just make casting harder, since you'd first have to cast down 
to Object and then back up to the class you want.

Hauke
Dec 03 2003
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Hauke Duden wrote:


 Berin Loritsch wrote:
 

 What we are talking about is leveraging the strong typing so that you
 can never *upcast*.


 
 
 Ah. I think I understand what you want. You just want to remove casting 
 altogether, thus only allowing what you call "implicit casts", i.e. 
 casts to a base type?
 
 Wouldn't work. For example, sometimes you just have to pass a sub class 
 thorugh a program component that only knows the base class and cast it 
 back up to the original type afterwards.


Bad code.  Shouldn't do it.  More often than not, upcasting from a base type
other than the generic "object" is a poor substitute for what you really
want.  That's what interfaces are for.  You specify your contracts in the
interface, and pass your object so that the code uses the interface AND NOTHING
ELSE.


 Btw, what *I* thought you meant is to use temporary variables to perform 
 a real cast. I.e. allow assigning any type to a local variable when that 
 variable is constructed:
 
 Bar getBar();
 void setFoo(Foo foo);
 
 Foo foo=getBar();
 
 but not
 
 setFoo(getBar());
 
 for unrelated types Foo and Bar.
 
 THAT would water down D's type system!


Please, no.


 The only upcast that should ever work is one from the generic object type
 to an Interface.  Once there is a definite type, no more upcasting.


 
 
 That would just make casting harder, since you'd first have to cast down 
 to Object and then back up to the class you want.


That is the point.  Some things like collections *have* to use Object, so at
that time you upcast to the interface you want.  Notice, that I limited the
upcast from object to interfaces?

Granted this would nicely fit the way I work--but not everyone in the world.
Dec 03 2003
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Berin Loritsch wrote:

 Wouldn't work. For example, sometimes you just have to pass a sub 
 class thorugh a program component that only knows the base class and 
 cast it back up to the original type afterwards.


 
 
 Bad code.  Shouldn't do it.  More often than not, upcasting from a base 
 type
 other than the generic "object" is a poor substitute for what you really
 want. 


That is a pretty sweeping statement you make there. Here's an example 
against that:

Consider an image manupulation algorithm that takes quite a while. It 
takes a bunch of objects of type Bitmap and works on them. However, YOUR 
bitmaps are of the type BitmapWithName, which is derived from Bitmap.

The algorithm calls a progress function regularly, in which you update 
your GUI to reflect the progress. The current bitmap the algorithm works 
on is passed to that function, as a Bitmap reference. Since you want to 
display the name of the current bitmap and you know that all objects you 
feed the algorithm are your own BitmapWithName objects, you have to cast 
the object you get up to that class, in order to retrieve its name.

Presto: an upcast from a class other than Object.

Hauke
Dec 03 2003
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Hauke Duden wrote:

 Berin Loritsch wrote:
 

 Wouldn't work. For example, sometimes you just have to pass a sub 
 class thorugh a program component that only knows the base class and 
 cast it back up to the original type afterwards.




 Bad code.  Shouldn't do it.  More often than not, upcasting from a 
 base type
 other than the generic "object" is a poor substitute for what you really
 want. 


 
 
 That is a pretty sweeping statement you make there. Here's an example 
 against that:


;P You noticed?


 
 Consider an image manupulation algorithm that takes quite a while. It 
 takes a bunch of objects of type Bitmap and works on them. However, YOUR 
 bitmaps are of the type BitmapWithName, which is derived from Bitmap.
 
 The algorithm calls a progress function regularly, in which you update 
 your GUI to reflect the progress. The current bitmap the algorithm works 
 on is passed to that function, as a Bitmap reference. Since you want to 
 display the name of the current bitmap and you know that all objects you 
 feed the algorithm are your own BitmapWithName objects, you have to cast 
 the object you get up to that class, in order to retrieve its name.
 
 Presto: an upcast from a class other than Object.


Counter example:

You know that somethimes there will be objects that must be namable, so
you create an interface to represent that concern called "Namable" which
essentially consists of a getName() method.  Your new BitmapWithName object
implements the Bitmap and Namable interfaces.  The Progress function performs
something like this:

char[] name = "";
if ( progressiveObject instanceof Nameable )
{
     Nameable obj = progressiveObject;
     name = obj.getName();
}

At least that is what you do in Java.

If you make your contract directly with an Object, your code is bound to that
object.  If that object is horribly written and is cast aside later on your
code will break in many unexpected ways.  However if you make a contract with
an interface, ANY object that implements that interface can be used.  In fact
your functions become more flexible and reusable because the progress function
no longer expects to deal with Bitmap objects, but anything that can be namable.
Dec 04 2003
parent Hauke Duden <H.NS.Duden gmx.net> writes:
Berin Loritsch wrote:

 Presto: an upcast from a class other than Object.


 
 
 Counter example:
 
 You know that somethimes there will be objects that must be namable, so
 you create an interface to represent that concern called "Namable" which
 essentially consists of a getName() method.  Your new BitmapWithName object
 implements the Bitmap and Namable interfaces.


That would work too, but you cannot FORCE programmers to use interfaces 
for everything. In particular, if you just need a quick prototype (for 
example, for a demo that needs to be done yesterday) you'd probably want 
the option to just declare the functionality you need directly in the 
object class, without having to define additional interfaces.

Also, right now there is a serious limitation to D's interfaces that 
pretty much prevents them from being used in that way. I always wanted 
to write an longer post about this issue, but never got around to it.

The main problem is that if a class implements an interface A and a 
derived class wants to implement a sub-interface "B" of A, then you have 
to re-implement all the functions of A again (probably with stubs that 
call the base class). This is a serious issue if you build an interface 
hierarchy and want to reuse an existing implementation of a 
base-interface as a basis for an implementation of a more specific 
interface (which you often want!). You end up writing dozens of 
stub-methods that do nothing except calling the base class 
implementation, for each and every class and every interface it implements.

I'll try to write the post on that topic tonight, with a better 
explanation of what I mean. This issue is actually pretty important to 
me, even critical for my decision of whether I'll ever switch to D. So I 
want to make sure that my point is understandable.

Hauke
Dec 04 2003
prev sibling next sibling parent Ant <Ant_member pathlink.com> writes:
In article <bql580$4ki$1 digitaldaemon.com>, Russ Lewis says...

Walter wrote:

 The postfix cast does look good, but I don't see it has much advantage over
 the prefix cast.


I like the idea of postfix cast because it makes long chained 
expressions easier to read.  IMHO, this:
	a.b.cast(Foo).c.d.cast(Bar).e.f
is easier to read than:
	(cast(Bar)((cast(Foo)(a.b)).c.d)).e.f


I like castTo better because is more explicit and
avoids confusion for someone used to older languages.

a.b.castTo(Foo).c.d.castTo(Bar).e.f

Ant
Dec 03 2003
prev sibling parent reply "Matthew Wilson" <matthew.hat stlsoft.dot.org> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:bql580$4ki$1 digitaldaemon.com...

 Walter wrote:

 The postfix cast does look good, but I don't see it has much advantage




over

 the prefix cast.


 I like the idea of postfix cast because it makes long chained
 expressions easier to read.  IMHO, this:
 a.b.cast(Foo).c.d.cast(Bar).e.f
 is easier to read than:
 (cast(Bar)((cast(Foo)(a.b)).c.d)).e.f


Hmmm. There's some mileage in the C++ philosophy of not facilitating the
ease-of-expression; maybe casts should be nasty to type?
Dec 03 2003
parent Ant <Ant_member pathlink.com> writes:
In article <bqmiig$2901$1 digitaldaemon.com>, Matthew Wilson says...

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:bql580$4ki$1 digitaldaemon.com...

 Walter wrote:

 The postfix cast does look good, but I don't see it has much advantage




over

 the prefix cast.


 I like the idea of postfix cast because it makes long chained
 expressions easier to read.  IMHO, this:
 a.b.cast(Foo).c.d.cast(Bar).e.f
 is easier to read than:
 (cast(Bar)((cast(Foo)(a.b)).c.d)).e.f


Hmmm. There's some mileage in the C++ philosophy of not facilitating the
ease-of-expression; maybe casts should be nasty to type?


You might be right but anyway you cut it
shoud be easy to read,
that's the only advantage we a seeking with the postfix idea.

Ant
Dec 04 2003
prev sibling parent Ant <Ant_member pathlink.com> writes:
In article <bkq9th$17fn$1 digitaldaemon.com>, Dario says...

I would prefer something like:
.    class A {}
.    class B:A {void func(){}}
.    A b = new B;
.    B.cast(b).func();
Rather than having to write:
.    (cast(B) b).func();
Isn't the former easier to read?

Consider more complex code like the following:
.    ((CK) ((CA) list[i]).kid).func();
That becomes:
.    CK.cast(CA.cast(list[i]).kid).func();



list[i].castTo(CA).kid.castTo(CK).funct
or list[i].cast(CA).kid.cast(CK).funct
or list[i].to(CA).kid.to(CK).funct

looks even better to me!

and 
     list[i].castTo(MyClass*)
looks better then
     Class*.cast(list[i])
or
     (Class*).cast(list[i])

Ant
Sep 23 2003
prev sibling parent Robert <Robert_member pathlink.com> writes:
from:  http://www.digitalmars.com/drn-bin/wwwnews?D/19990

I've remembered that I thought about cast expression this April
(but independently of D,)
and have found the memo which was written then.


I introduced two types of *postfix* cast in the memo.
One is `down_cast' for down cast and another is `cast' for the other cast
(exactly I introduced also `up_cast' for the case of multiple inheritance.)

e.g.)
A a = new A;
B b = a.cast(B);
C c = a.down_cast(D);

The memo also says as follows:

Casts are similar to constructors,
but casts are opposite processes to constructors.
Because "A a = new A; B b = a.cast(B);" makes
B's instance from A's instance though the `cast' is A's member function.
It gives the same result as new B(a) (if B(A) is defined,)
however, the cast can be implemented even if B knows *nothing* about A.
This is a very important aspect of casts,
and supports that casts must be subject to the casted classes.

Casts are treated as member functions, but the syntax is special.
Because return value types are given from the arguments.
It's a unique property of casts.
Many cast functions seem to have no arguments (the same arguments),
but they can be overloaded.

`implicit' keyword allows implicit cast if not ambiguous.
Overloaded casts should be explicit by default.

e.g.)
struct Point {
public int x, y;
public Size cast() {
return new Size(x, y);
}
public implicit LongPoint cast() {
return new LongPoint(x, y);
}
}
Point pt;
Size siz = pt.cast(size);
LongPoint lpt = pt;

Cast methods can have some additional arguments if necessary.

Down casts must be treated with especial care,
must not be overloaded, and make no instances,
so they should be distinguished from normal casts and
should be done with special keyword.


Though some specs may be bizarre,
I would appreciate hearing advices for it.

Robert (Japanese)
Dec 07 2003