Java-style csv-list of interfaces to implement

[Gama11]

Implementing several interfaces quickly becomes very verbose on Haxe:

class Test implements A implements B implements C implements D {}

It would be nice if the following was also allowed - much more readable while not losing any information:

class Test implements A, B, C {}

Considering from Haxe 2 -> 3 there was a change to make implements more similar to Java, this seems like a sensible request.

[Simn]

Let's not introduce redundant syntax to save a few keystrokes on type declaration level.

[Gama11]

I think this is not so much about keystrokes, rather readability. ;)

[andyli]

Just to explain a bit more:
This kind of syntax changes made sense at the time of haxe 2-> 3, because it was a major version release. At this moment we're working on 3.2 which is a minor version release, so we want to avoid syntax changes.

[Gama11]

@andyli Well I wasn't saying that this should be in the next minor version, I just wanted to throw this idea out there in general. I don't think all currently open issues are going to be resolved in 3.2? ;)

[andyli]

I understand, but generally we treat the issue list as some kind of todo list, so we don't keep request that is not agreed to be implement here. Or else the issue list could become very long and it would be hard to maintain.

Specifically this syntax change is rather minor - it is not fixing or improving some functionality of the language. If you have strong feeling about it, bring it up when we are discussing haxe 4.

[Gama11]

Sure, that makes sense.

A Haxe 4-label might make sense for these sort of issues, so you can easily group possible changes (even if closed)?

[andyli]

Having a label, like not-considered-at-this-moment would be possible. But I am not sure if we will really go through it from time to time when we advance a major version...

If it were forgotten, it could mean that it is not that important. If it is important, it will be brought up by someone again anyway (e.g. short lambda ;)).

[Justinfront]

Gama11

I am not convinced it's a suitable feature for Haxe4.

It's a small feature that seems to have no president elsewhere, ie the general pattern is not one that applies in other areas, so it could leave a user scratching their head, and it's adding code complexity for little gain, and would cost in core developer time and add more bloat to documentation, and it might be a feature only used by you.
I found for Java target just moving the implements to new lines provides plenty of clarity.

class Test extends JFrame
implements KeyListener
implements MouseListener
implements MouseMotionListener
{

}

The argument would be more valid if the proposal related to the concept more widely for instance on using and import, for instance theoretically you could have such structures nested for imports...

import flash. display. Sprite, MovieClip, events. MouseEvent, KeyboardEvent;

But it's probably not easy to follow? But maybe there are ways this could work, but just suggesting for interfaces is rather a piecemeal add on like how as3 does typed arrays by creating the Vector stuff so for me it would be just another special case thing to learn about. I understand the reason for the proposal but conservative policy on language features is what makes Haxe a good language, which is probably why it has been closed so quick.

Best Justin

[RealyUniqueName]

It's time to think again )