"Axel Kittenberger" <axel@dtone.org> wrote in message news:9ngav1$1jfn$1@digitaldaemon.com...

> The main argument against Pascal style typecasts is, they are difficult to parse, at least I guess they're acutallly very difficult to parse for a c like language. Pascal is easier since it types are simpler defined.
>
> Try following C code with it:
> a = (char **) b;
> a = char**(b); // Looks also very ugly doesn't it?
>

Trying that in Delphi .. right, it can't be compiled in Delphi without a type alias, which IMHO is no great loss to Delphi,  ie

type
  pchar = ^char;
  ppchar = ^pchar;

procedure Test;
var
  p: pointer;
  i: integer;
begin
 i := 42;
 p := ppchar(i); // this works
 // this doesn't compile p := ^pchar(i);
end;



> According to a function paradigm I guess following would in example be
> proper:
> cast<char**>(a);
>
Maybe, but the (type)(expr) syntax just strikes me as very wrong. Why not
cast(type, expr), ie

a = cast(char**, b);


> In my presonal view the discussions from Pascal vs. C where battled on another field than where the programmers hearts lay, they discussed for typedefs again type, structs agains records, include against uses, etc.
but
> I think in reality it was only the feeling for '{' vs 'BEGIN'. :o)
>
Maybe so. { } instead of BEGIN & END  is one of the things that I'm liking about Java :)

Anthony Steele wrote:

> Maybe, but the (type)(expr) syntax just strikes me as very wrong. Why not
> cast(type, expr), ie
>
> a = cast(char**, b);

Nice...I like that syntax because it gives a clear division between the type, the data, and the surrounding code.

How about using the property paradigm?

a = b.cast(char**);

Comments?

Russ Lewis wrote:
> 
> Anthony Steele wrote:
> 
> > Maybe, but the (type)(expr) syntax just strikes me as very wrong. Why not
> > cast(type, expr), ie
> >
> > a = cast(char**, b);
> 
> Nice...I like that syntax because it gives a clear division between the type, the data, and the surrounding code.
> 
> How about using the property
> 
> a = b.cast(char**);
> 
> Comments?

I like treating cast just like a function.  Once
novice programmers have learned about functions,
they don't have to learn about cast syntax, only
what the cast function does.

You might also consider:

  cast(expr, type)

This feels more natural to me; "cast this to that".
Maybe the type is too important to be hidden after
a big expression?

Not sure about the property paradigm.  Looks as if
you could overwrite the cast function in your class.

Russ Lewis wrote:

> Anthony Steele wrote:
> 
> 
>>Maybe, but the (type)(expr) syntax just strikes me as very wrong. Why not
>>cast(type, expr), ie
>>
>>a = cast(char**, b);
>>
> 
> Nice...I like that syntax because it gives a clear division between the type,
> the data, and the surrounding code.
> 
> How about using the property paradigm?
> 
> a = b.cast(char**);
> 
> Comments?
> 
> 

Nice.  But in that case, how about:
a = b.cast("char**");

This would allow the function parsing rule to remain unaltered.  Of course it would appear to open one up to:

char [] castVar;
castVar = "char [5]"
if flag	then castVar = "int";
a = b.cast(castVar);

And that might not be so nice.

James Gilbert wrote:

> You might also consider:
>
>   cast(expr, type)
>
> This feels more natural to me; "cast this to that".
> Maybe the type is too important to be hidden after
> a big expression?

At first I liked your idea...but yeah, now that you mention it, I do prefer to have the type in front as it seems more readable.

> Not sure about the property paradigm.  Looks as if
> you could overwrite the cast function in your class.

That might not be altogether a bad thing....dunno

> Nice.  But in that case, how about:
> a = b.cast("char**");

Well to allow easy parsing how about bracing types always in <> squares. a = b.cast<char**>;

if you want to cast to char **
or
a = b.cast(a);

if you want to cast to the typeof a.

same paradigm for sizeof,
sizeof<char>    ---> 1
sizeof(a)       ---> if a is an int32 in example 4

if prefix or postfix is better gets more obvious if you've longer chains suppose you want to cast a to an int, but over an extra step over typeof b. a = 3 + a.cast(b).cast<int>;

or

a = 3 + cast<in> cast(b) a;

okay it isn't obvios as both have +es and -es....

- Axel

Axel Kittenberger wrote:

> if you want to cast to char **
> or
> a = b.cast(a);
>
> if you want to cast to the typeof a.
>
> same paradigm for sizeof,
> sizeof<char>    ---> 1
> sizeof(a)       ---> if a is an int32 in example 4

(cheer)

Good thinking, I *like*!

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:3B9F6EF2.2030709@earthlink.net...


> This would allow the function parsing rule to remain unaltered.
>   Of course it would appear to open one up to:
>
> char [] castVar;
> castVar = "char [5]"
> if flag then castVar = "int";
> a = b.cast(castVar);
>
> And that might not be so nice.
>

 or in  the functional style

 a = cast(castVar, b);

Sorry, a few weeks of Java have convinced me even more that while OO is the most powerfull tool in a programmer's toolbox, it shouldn't be the only one :) Sometimes a function is all you need.

I haven't read the spec too closely, but I would have thought that this is impossible - as the cast is actually done at compile time for simple types - it's just a  compile-time check, since all pointers are untyped in machine code.

The type param might have to be a type (syntactically checkable at compile
time), not a string (can't make sure that it's a valid type at all).

Using a string can cause confusion - if you cast a var to a type unknown at
compile-time, where do you put the value returned? In the example above,
what is a sensible type for 'a', given that castVar can contain any type,
even one that the program's user just entered.
I could see this possibly working somehow for 'soft' casts on COM interfaces
or class types & using a base type to recieve the value, but not with
primitive types like char** ;

Axel Kittenberger wrote

> a = b.cast(a);
> if you want to cast to the typeof a. - same paradigm as for sizeof,

or a = cast(b, a);

Nice. Would make coding simple & flexible and like sizeof, it can be resolved at compile time. I hope Walter sees that!

Axel Kittenberger wrote in message <9ngav1$1jfn$1@digitaldaemon.com>...
>Well looking at the parser, and because we're lazy types you can cut the
>cast keyword away. People are lazy, and that's why they don't want to write
>BEGIN and END all the time, in my eyes that's all behind it :/
>In my presonal view the discussions from Pascal vs. C where battled on
>another field than where the programmers hearts lay, they discussed for
>typedefs again type, structs agains records, include against uses, etc. but
>I think in reality it was only the feeling for '{' vs 'BEGIN'. :o)


My trouble with Pascal is I found that I spent half my programming time trying to get around some language prohibition. C was a breath of fresh air for that.  I don't want to lose that in D.