Removing "implements Dynamic" (and implements Dynamic<T>)

[Simn]

Just found this in the unit tests:

#if !hl // no support for implements Dynamic yet

So it should probably be implemented. Or we take the opportunity and remove this annoying feature.

[fponticelli]

Kill it! :)

[nadako]

I never needed it for Haxe code, however for crazy dynamic language extern it sometimes make sense, e.g. https://github.com/nadako/hxnodejs-commander/blob/master/src/js/npm/commander/Command.hx. Maybe make it an extern-only feature? (although maybe an @:op(a.b) or something might be a better alternative).

[Justinfront]

If it was really renamed to dynamite then it would make users feel more guilty when using, I think that it would reduce it's use, and make Simns life simpler, but Haxe is pragmatic and that's really good... but probably extremely annoying to the implementation, I don't use Dynamic but it's really important for new users - and they all stop using, it once they have properly transitioned, but to make Haxe less accessible is not productive.

[RealyUniqueName]

Let's rename Dynamic to Unsafe or Hack :)

[Justinfront]

Untyped is more accurate but Unsafe seems ideal and if you just changed it for Haxe 4 users would be prompted to check codebases.

[ncannasse]

It was mostly used for Flash 8 interaction so yes I'm ok to remove it for Haxe 4 . I guess that also stands for implement Dynamic<T>

[ncannasse]

And no renaming Dynamic is out of question, it would break a lot of code for no valid reason.

[nadako]

Yeah, Dynamic is a fine name for the type itself. I think it's similar to dynamic in C# (although it's much more used in Haxe than in C#).

This issue is about implementing Dynamic which indeed seems like a weird feature nowadays. I'm all for removing it (though we should think of some kind of replacement for externs like I linked above).

[RealyUniqueName]

I +1 implements Dynamic for externs: https://github.com/HaxeFoundation/haxe/blob/development/std/php7/StdClass.hx#L5

[nadako]

Let's restrict it for externs for now then, and then maybe remove in favor of some good solution for externs.
This will allow simplifying some stuff in gencommon (right now it tries too hard when implementing Dynamic on classes).

If you wish I can make a PR for this.

[Justinfront]

Removing Dynamic will break a lot of libraries, this seems really problematic suggestion when I look at it from the perspective of developers using Haxe for real projects.

For instance git version of polygonal-ds has 181 uses in 110 *.hx files, I am sure he can work round but larger projects like OpenFL, Flambe etc... ecosystems that is going to take quite an effort Actuate is full of Dynamic.

When I search my haxelib folder through only *.hx files for the word "Dynamic".
19321 results for 14287 files.
Since it's a work computer the 60 odd libraries are all recent, half github versions of libraries covering all the toolkits, ( none of my own libraries uses any Dynamic so it's likely feasible to work without Dynamic ) but many tweening libraries rely really heavily on Dynamic.

That's about 1.3 uses of 'Dynamic' per current haxe library class perhaps more, to remove the feature will kill many haxelib projects even with fazed introduction, that's worse than just renaming it!

Loosing libraries that are used rarely, will reduce the possible soution space which already small compared to some languages.

Not sure on best approach, but I think that such a change needs to include an audit of current haxelib and larger community... or you might end up alienating some users, including comercial ones.

I am all for removing Dynamic in theory... but it in practice it could be a real worry, I would be up for banning use for new libraries but historic ones that's harder. Playing devils advocate, just airing my worry - removing Dynamic to make the compiler more robust but force significant changes in hundreds of Haxelibs, broken libraries has as much of negative effect on Haxe as obscure compiler bugs, any PR needs to address this possible problem.

[Justinfront]

Summary 1.3 Dynamics per average haxelib class feel free to add your own local stats.

[Simn]

Guys please, this is about implements Dynamic, nothing else.

[Justinfront]

oh sorry.

[Justinfront]

To use a MovieClip in flash you use implements Dynamic, guess flash is less relevant now.

[RealyUniqueName]

flash.display.MovieClip is an extern.

[Justinfront]

so this would still be allowed?
public class MyAnimation extends MovieClip

[nadako]

Yes, but how is this related to implements Dynamic? Let's not pollute the thread with irrelevant discussions.

[Simn]

The removal of implements Dynamic is blocked on haxe.remoting being a thing. Related issue #6586.

[back2dos]

Can you not make Connection an abstract and then define @:op(a.b) it, or something? Or let the generated code from Proxy/AsyncProxy just not rely on this feature (and actually generate the resolve calls)? I don't think anyone uses Connection directly, and even if they did, they can use resolve.

[Simn]

Maybe, I don't know. :) I don't really want to mess with haxe.remoting myself, in part because I have 0 test cases for it.

[back2dos]

I think it's safe to say that if you remove implements Dynamic<Connection> and adjust Proxy to generate cnx.resolve("ident") instead of cnx.ident it'll be just fine.

[jgranick]

Removing this feature will break these features in OpenFL:

• openfl.net.URLVariables

Here is an example from ActionScript:

// The first method passes the string to be decoded to the URLVariables class constructor:
var urlVariables:URLVariables = new URLVariables("firstName=Tom&lastName=Jones");
lbl.text = urlVariables.lastName + "," + urlVariables.firstName;

// The second method uses the decode() method to parse the URL encoded string:
var urlVariables:URLVariables = new URLVariables();
urlVariables.decode("firstName=Tom&lastName=Jones");
lbl.text = urlVariables.lastName + "," + urlVariables.firstName;

Workaround: Using abstract will allow the same functionality, but extending in another class or using Std.is will fail

• openfl.display.ShaderData

var shader = new Shader ();
shader.glFragmentSource = "...";
shader.glVertexSource = "...";
shader.data.myAttribute.value = [ 1, 0, 0, 1 ];

Workaround: Using abstract or an ordinary Dynamic will allow the same functionality, but extending in another class or using Std.is will fail

• openfl.display.MovieClip (using -Dopenfl-dynamic)

var example = Assets.getMovieClip ("library:UIDemo");
example.header.title.text = "Hello World";
trace (example.footer.width);

Workaround: There is no workaround for this behavior without breaking significant code.

cast (cast (example.getChildByName ("header"), DisplayObjectContainer).getChildByName ("title"), TextField).text = "Hello World";
trace (example.getChildByName ("footer").width);

• openfl.errors.Error (using -Dopenfl-dynamic)

Workaround: This might not be significant. Without -D flash-strict, flash.errors.Error implements Dynamic. I am unsure how much code relies on this, though subclassing could work.

So I guess we have some work to do, but the MovieClip class is most painful

[ncannasse]

@jgranick thanks for taking the time to report the usages openfl is making of it

[jgranick]

We've made the changes on our end, for some of the types, we are using the following pattern:

@:forward() abstract CustomType(Dynamic) from Dynamic to Dynamic {
    public function new () {
        this = {};
    }
}

If there are any issues with this pattern (or ways we could better emulate the previous behavior) please let me know. I understand the motivation

[Simn]

Closing this in favor of #6586 which is pretty much a superset.