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

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.

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

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

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

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

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

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.

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

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.