www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - grep

reply Dee Girl <deegirl noreply.com> writes:
One good argument for a cast keyword is that persons can grep for it. But I
just compiled this program:

void main() {
    int a = 4;
    float b = mixin("ca" ~ "st(float)(a)");
}

It seems like string mixin makes it possible for bad persons to avoid being
exposed by a grep. Just a thought, Dee Girl ^_^
May 09 2008
parent reply janderson <askme me.com> writes:
Dee Girl wrote:

 One good argument for a cast keyword is that persons can grep for it. But I
just compiled this program:
 
 void main() {
     int a = 4;
     float b = mixin("ca" ~ "st(float)(a)");
 }
 
 It seems like string mixin makes it possible for bad persons to avoid being
exposed by a grep. Just a thought, Dee Girl ^_^



I guess your not being serious but in case you are, you want to make bad 
coding difficult to do and good coding easy.  People area not likely to 
go to that much effort to circumvent cast.  There are a couple of other 
ways to get around cast:

//ie
class A
{

};

class B : A
{

};

	B[] b;
	b ~= new B;
	A[] a = b;
	a ~= new A;
//b[1] Is not an A type (not a B type), but is essentially a reinterpret 
A -> B.


Unions are another one.
You could also hide your cast in a lib file.
May 09 2008
next sibling parent reply Dee Girl <deegirl noreply.com> writes:
janderson Wrote:


 //ie
 class A
 {
 
 };
 
 class B : A
 {
 
 };
 
 	B[] b;
 	b ~= new B;
 	A[] a = b;
 	a ~= new A;
 //b[1] Is not an A type (not a B type), but is essentially a reinterpret 
 A -> B.



Your example compiles but it was so good if it did not. Modifiable arrays
should never be covariant! Why did D make the same mistake that Java and Eiffel
did? Newer languages should learn from the mistakes of the old languages. This
is more than a bit disappointing. Dee Girl
May 09 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Dee Girl wrote:

 janderson Wrote:
 

 //ie
 class A
 {

 };

 class B : A
 {

 };

 	B[] b;
 	b ~= new B;
 	A[] a = b;
 	a ~= new A;
 //b[1] Is not an A type (not a B type), but is essentially a reinterpret 
 A -> B.



 Your example compiles but it was so good if it did not. Modifiable arrays
should never be covariant! Why did D make the same mistake that Java and Eiffel
did? Newer languages should learn from the mistakes of the old languages. This
is more than a bit disappointing. Dee Girl



Java learned its lesson in 1.5... List<B> can't be cast to a List<A> 
implicitly, only to a List<? extends A>.
May 10 2008
prev sibling parent reply janderson <askme me.com> writes:
Dee Girl wrote:

 janderson Wrote:
 

 //ie
 class A
 {

 };

 class B : A
 {

 };

 	B[] b;
 	b ~= new B;
 	A[] a = b;
 	a ~= new A;
 //b[1] Is not an A type (not a B type), but is essentially a reinterpret 
 A -> B.



 Your example compiles but it was so good if it did not. Modifiable arrays
should never be covariant! Why did D make the same mistake that Java and Eiffel
did? Newer languages should learn from the mistakes of the old languages. This
is more than a bit disappointing. Dee Girl




I agree its not particularly good.  Then again, if your using casting 
for anything you should think twice about what your doing.  I think the 
reason for allowing A[] a = b; is polymorphism.  The problem comes when 
you append a new A.  I think the solution would be to make A[] invariant 
or const and enforce it by the compiler.   That way you can't add 
anything to B[] indirectly but can still pass it into functions that 
take invariant A[].
May 10 2008
parent Dee Girl <deegirl noreply.com> writes:
janderson Wrote:


 Dee Girl wrote:

 janderson Wrote:
 

 //ie
 class A
 {

 };

 class B : A
 {

 };

 	B[] b;
 	b ~= new B;
 	A[] a = b;
 	a ~= new A;
 //b[1] Is not an A type (not a B type), but is essentially a reinterpret 
 A -> B.



 Your example compiles but it was so good if it did not. Modifiable arrays
should never be covariant! Why did D make the same mistake that Java and Eiffel
did? Newer languages should learn from the mistakes of the old languages. This
is more than a bit disappointing. Dee Girl



 
 I agree its not particularly good.  Then again, if your using casting 
 for anything you should think twice about what your doing.



The codes fails without any casts.


  I think the 
 reason for allowing A[] a = b; is polymorphism.  The problem comes when 
 you append a new A.



It comes when you modify the array in anyway. As shown in
http://www.pmg.csail.mit.edu/papers/popl97/node19.html (I am taking class now
so it is very fresh in my mind ^_^)


  I think the solution would be to make A[] invariant 
 or const and enforce it by the compiler.   That way you can't add 
 anything to B[] indirectly but can still pass it into functions that 
 take invariant A[].



I think B[] to invariant(A[]) can not work. These work:

B[] -> const(A[])
const(B[]) -> const(A[])
invariant(B[]) -> invariant(A[])

There are more that work but they can be deduced from the transitivity rule.
For example invariant(B[]) -> const(A[]). Dee Girl
May 10 2008
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
janderson wrote:

 I guess your not being serious but in case you are, you want to make bad 
 coding difficult to do and good coding easy.  People area not likely to 
 go to that much effort to circumvent cast.  There are a couple of other 
 ways to get around cast:
 
 //ie
 class A
 {
 
 };
 
 class B : A
 {
 
 };
 
 	B[] b;
 	b ~= new B;
 	A[] a = b;
 	a ~= new A;
 //b[1] Is not an A type (not a B type), but is essentially a reinterpret 
 A -> B.
 



But array b has no element at index 1, it's length is still 1.

This gets the desired effect:

  	B[] b;
  	b ~= new B;
  	b ~= new B;
  	A[] a = b[0..1];
  	a ~= new A;

Now, the second element of b will be an A.  On the other hand, appending 
to slices could easily be considered bad style.
May 09 2008
parent Dee Girl <deegirl noreply.com> writes:
torhu Wrote:


 janderson wrote:

 I guess your not being serious but in case you are, you want to make bad 
 coding difficult to do and good coding easy.  People area not likely to 
 go to that much effort to circumvent cast.  There are a couple of other 
 ways to get around cast:
 
 //ie
 class A
 {
 
 };
 
 class B : A
 {
 
 };
 
 	B[] b;
 	b ~= new B;
 	A[] a = b;
 	a ~= new A;
 //b[1] Is not an A type (not a B type), but is essentially a reinterpret 
 A -> B.
 



 But array b has no element at index 1, it's length is still 1.
 
 This gets the desired effect:
 
   	B[] b;
   	b ~= new B;
   	b ~= new B;
   	A[] a = b[0..1];
   	a ~= new A;
 
 Now, the second element of b will be an A.  On the other hand, appending 
 to slices could easily be considered bad style.



I do not understand D arrays yet to know why appending to slices is bad style.
But there is no need for slices. The following program compiles and runs. D
makes a textbook mistake by making arrays covariant. Why nobody gets arrays
right?

import std.stdio;

class A {}
class B : A {}

void main()
{
    B[] b = new B[2];
    A[] a = b;
    a[0] = new A;
    a[1] = new B;
    writeln(b[0]);
}

It is correct to allow B[] to be a subclass of const(A[]), but B[] can not be a
subclass of A[] because elements of A[] can be written to and end up in the B[]
array. Could D2 repair this bug? Dee Girl
May 09 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/05/2008, Dee Girl <deegirl noreply.com> wrote:

 Could D2 repair this bug? Dee Girl



Yes. That's why it's exciting to be involved in an evolving language.

You need a bugzilla account to report bugs. Just sign up over at
http://d.puremagic.com/issues/

Report it, and wait. It might not get fixed immediately, but it will
be in the queue.
May 10 2008