Support Rest on non-extern methods too

[Simn]

I need an issue ID to write tests.

[Simn]

@ncannasse: Any objections to merging this? It works just like in AS3 where you get an array with the excess arguments.

[waneck]

Can we make it so that we get a haxe.ds.Vector instead of an Array? This would be nice to make it work with the native C# and Java rest arguments.

[Simn]

I still don't understand how this is even relevant to native representations.

[nadako]

I wonder if we need to add tests for extern Rest now that we have tests for non-extern Rest :-)

[waneck]

I meant that it would be nice that Rest on non-extern would be compiled like the actual extern Rest, on platforms that support Rest arguments

[Simn]

But then you would generate the extern-like call anyway without any array initialization, so I still don't see the point.

[waneck]

I'm not sure I understand - at least on Java (and IIRC on C# as well), you actually use the rest parameters as a native array, so they would be typed correctly when you declare a new Rest parameters function

[Simn]

That's getting too complicated for me again so let's forget about it for now.

[nadako]

The idea is good, let's not give up so quickly and wait for @ncannasse to say something 😉

[waneck]

I agree with nadako. It was just an idea, I can probably figure something out from the Java/C# side so it generates the native signature correctly

[Simn]

It's not worth it though because all it does is save you typing [ and ].

[waneck]

Allowing to override Rest functions would be a nice reason to allow this

[nadako]

If we're talking java/cs, it can do more that that, considering target interoperability.

For example it takes more than just [ ] when you want to create haxe array in C#, so it would be nice to be able to generate/override native rest-arg C# function (public void doStuff(int a, params string[] b)). In that case it indeed would be good to have haxe.ds.Vector as an underlying type for Rest.

After all, abstracts were designed to hide native stuff, so I even think it's okay to have different undelying types for different platforms (Array for flash/js, haxe.ds.Vector for Java/C#).

[waneck]

That's what I meant when I said to change the underlying type to Vector. Sorry I wasn't clear

[waneck]

Let's reopen this. I think it's worth - at least to have a better discussion about it.

[nadako]

ping @ncannasse :)

[ncannasse]

There's a bit of a design issue between a "native extern" where you want the rest parameters to be passed as-it and the "haxe extern" that needs to be passed as an Array. We tend to compile the whole Haxe code at once, but this feature would clearly break the ability to use haxe externs.

Any idea ?

[nadako]

Good point

[Simn]

What are "Haxe externs" actually used for?

[ncannasse]

For example : sharing a Haxe/JS library among several projects ?

[Simn]

We could generate Rest as arguments on JS target. But again I feel this is getting to complicated and we should allow rest args only for externs. In that case we do not have to worry about the distinction because native externs are the only ones that can make sense of varargs.

[nadako]

Let's not introduce this for 3.2 and think some day later. I personally don't find rest args very useful and i can do that with macro anyway.

[nadako]

OTOH, the native method override argument is still valid

[ncannasse]

if cl_extern || is_override ?

[waneck]

At some point we'll have to deal with these kind of differences (native extern vs haxe-generated extern).