↑ ↓ ← → 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 ^_^
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓ ← → 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>.
↑ ↓
← → 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[].
↑ ↓ ← → 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
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓
← → "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.
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next