A problem with array

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

A problem with array

Ali Jaya Meilio Lie
Hello list, i have a problem.

Ok i have this code:
class Foo
{
 public function new(){}
 public function foo()
 {
  trace('foo');
 }
}

class Bar extends Foo
{
 public function bar()
 {
  trace('bar');
 }
}

And this code
function test(a:Array<Foo>)
{
 for(n in a) n.foo();
}

And this code
var a:Array<Bar> = [new Bar(), new Bar()];

test(a); // failed
test(cast a); // compiled

I think the 'test(a)' should be compiled

---- 
Sent using a Sony Ericsson mobile phone
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: A problem with array

Owen Durni-2
If B is a subtype of A, MutableCollection<B> is not a subtype of
MutableCollection<A>.

Consider:

class B extends A;
class C extends A;

var arrb :Array<B> = new Array<B>();
var arra :Array<A> = new Array<A>(); //currently disallowed
arra.add(new C());

for( b in arrb )
  b.someFunctionNotInC();

//oops, we put C into an array of A (ok) but that array was also
aliased as an array of B. Now we have a C in our array of B and B and
C have nothing to do with one another.

Owen

On Fri, Nov 20, 2009 at 9:33 AM, Ali Jaya Meilio
<[hidden email]> wrote:

> Hello list, i have a problem.
>
> Ok i have this code:
> class Foo
> {
>  public function new(){}
>  public function foo()
>  {
>  trace('foo');
>  }
> }
>
> class Bar extends Foo
> {
>  public function bar()
>  {
>  trace('bar');
>  }
> }
>
> And this code
> function test(a:Array<Foo>)
> {
>  for(n in a) n.foo();
> }
>
> And this code
> var a:Array<Bar> = [new Bar(), new Bar()];
>
> test(a); // failed
> test(cast a); // compiled
>
> I think the 'test(a)' should be compiled
>
> ---- Sent using a Sony Ericsson mobile phone
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: A problem with array

David Bergman
There are few languages where aggregations are covariant. In Scala, one can stipulate the desired variance for any dependent type (such as an aggregation.) I think this is a low priority for a future haXe version, though. The standard variance rules seem to work pretty well.

This is often a source of confusion for even quite advanced software developers. For instance, the type adorners of C++ - such as 'const', '&' and '*' - are usually non-covariant. Heck, most advanced developers have a problem remembering whether overrides are covariant in parameters or not, and even worse with return types.

In most languages, we have (with the ordering being the regular "intrinsically convertible to" such as sub class relations, and '><' meaning not related):

        A  <  B   ===>  Param[A.f]  >  Param[B.f]  (i.e., overriding is contravariant in parameter types)

        A  <  B  ===>  Ret[A.f]  <  Ret[A.f] (i.e, overriding is covariant in return type)

        A  <  B  ===>  C[A]   ><  C[B], where C is an collection (parameterized) type (i.e., collections are invariant)

I deliberately avoid mentioning the distinction between a type and its referent type, even though the two are treated quite distinctly in some languages, with specific variance rules.

/David

On Nov 20, 2009, at 10:36 AM, Owen Durni wrote:

> If B is a subtype of A, MutableCollection<B> is not a subtype of
> MutableCollection<A>.
>
> Consider:
>
> class B extends A;
> class C extends A;
>
> var arrb :Array<B> = new Array<B>();
> var arra :Array<A> = new Array<A>(); //currently disallowed
> arra.add(new C());
>
> for( b in arrb )
>  b.someFunctionNotInC();
>
> //oops, we put C into an array of A (ok) but that array was also
> aliased as an array of B. Now we have a C in our array of B and B and
> C have nothing to do with one another.
>
> Owen
>
> On Fri, Nov 20, 2009 at 9:33 AM, Ali Jaya Meilio
> <[hidden email]> wrote:
>> Hello list, i have a problem.
>>
>> Ok i have this code:
>> class Foo
>> {
>>  public function new(){}
>>  public function foo()
>>  {
>>  trace('foo');
>>  }
>> }
>>
>> class Bar extends Foo
>> {
>>  public function bar()
>>  {
>>  trace('bar');
>>  }
>> }
>>
>> And this code
>> function test(a:Array<Foo>)
>> {
>>  for(n in a) n.foo();
>> }
>>
>> And this code
>> var a:Array<Bar> = [new Bar(), new Bar()];
>>
>> test(a); // failed
>> test(cast a); // compiled
>>
>> I think the 'test(a)' should be compiled
>>
>> ---- Sent using a Sony Ericsson mobile phone
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: A problem with array

Nicolas Cannasse
David Bergman a écrit :
> There are few languages where aggregations are covariant. In Scala, one can stipulate the desired variance for any dependent type (such as an aggregation.) I think this is a low priority for a future haXe version, though. The standard variance rules seem to work pretty well.

There was a time where you could declare Array<+Foo> for covariant types
in haXe, or Array<-Foo> for contravariant types. But this which quite
hard to get right and is no longer available.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: A problem with array

Justin Donaldson
Java is a good example of covariant collection types.
I think Java's implementation of covariant arrays "gets it wrong" (at least for my purposes):
http://www.pmg.csail.mit.edu/papers/popl97/node19.html
http://www.developertutorials.com/tutorials/java/java-theory-generic-050323/page2.html

This kind of approach will always rely on special run-time checks...  Checks that haXe isn't in a good position to enforce (practically) for every platform.

This seems like a negligible loss of flexibility imho... if Nicolas can get it working, it's great.  If not, no big deal.

-Justin


On Sun, Nov 22, 2009 at 11:17 AM, Nicolas Cannasse <[hidden email]> wrote:
David Bergman a écrit :

There are few languages where aggregations are covariant. In Scala, one can stipulate the desired variance for any dependent type (such as an aggregation.) I think this is a low priority for a future haXe version, though. The standard variance rules seem to work pretty well.

There was a time where you could declare Array<+Foo> for covariant types in haXe, or Array<-Foo> for contravariant types. But this which quite hard to get right and is no longer available.

Nicolas

--
haXe - an open source web programming language
http://haxe.org



--
Justin Donaldson
PhD Candidate, Informatics
Indiana University
http://www.scwn.net
aim: iujjd
twitter: jjdonald

--
haXe - an open source web programming language
http://haxe.org