Remove and rename some std stuff

[Simn]

• remove haxe.web
• remove haxe.unit
• rename haxe.xml.Fast (maybe add a better Fast)

[Simn]

Removing haxe.unit is blocked on #6461. That's the only place we use it though.

[nadako]

I'm not sure how I feel about haxe.unit removal. It's clearly inferior to things like utest, but OTOH having a standard way to test stuff would be great...

[Simn]

Easy: "The standard way to test stuff with Haxe is using -lib utest" (or whatever)

[back2dos]

Can we put List on the list?

[ncannasse]

We can add List if we move it to the compat library (haxe.web/unit should got there as well as haxe.xml.Fast maybe no?)

…

On Mon, Sep 18, 2017 at 3:39 PM, Juraj Kirchheim ***@***.***> wrote: Can we put List on the list? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6586 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwHRfKn0OxM8EEJdeFpOX3lwblUEDks5sjnJ_gaJpZM4PZ9Hn> .

[waneck]

The real problem with List is its insane default implementation. I think that we need more data structures in the standard library, not less.

[back2dos]

The real problem with List is its insane default implementation. I think that we need more data structures in the standard library, not less.

The implementation is only part of the problem. The biggest problem is that it pollutes the top-level. We could move it out to haxe.ds and then I wouldn't mind for it to exist there.

Similarly, we should decide what to do with Lambda. It's weirdly named. It creates lists. Doesn't inline, doesn't work on iterators. Maybe we should just get rid of that one too, given that comprehensions give you a far more efficient alternative for map/filter?

[Simn]

The problem with haxe.xml.Fast is that it is being used by haxe.rtti.XmlParser.

[Simn]

I think I'm done for now. Fast is an abstract now, so I think it can stay where it is.

[kevinresol]

How about moving List to haxe.ds?

[Simn]

Yes we can do that, too. Anyone wanna send a PR?

[kevinresol]

let me try

[Simn]

List has been moved. \o/

[Simn]

Oh yeah, there's another big one: haxe.remoting

This one is particularly annoying because it a) still has hardcoded compiler-support and b) uses implements Dynamic, which we also want to deprecate.

[nadako]

c) it's used by haxelib

[kevinresol]

c) it's used by haxelib

This one isn't a big deal I guess? After it is moved out, haxelib can simply change the reference.

[markknol]

Can js.jquery.* / js.swfobject.* also be removed from std?

[Simn]

Can js.jquery.* / js.swfobject.* also be removed from std?

I let @andyli comment on that.

I don't know what do to with haxe.remoting because of haxelib using it. I don't think it's a good idea to make haxelib depend on a haxelib...

[ibilon]

I don't think it's a good idea to make haxelib depend on a haxelib...

Haxelib can use submodule, and probably should instead of doing everything itself, so it's not too much of an issue. And that should not block this.

[Simn]

I'd be fine with that. Let's do it like this:

1. Add haxe.remoting to hx3compat
2. Add hx3compat as a submodule to haxelib
3. Remove haxe.remoting from std
4. Change haxe.remoting to not require implements Dynamic
5. Remove implements Dynamic
6. Investigate if we can get rid of the special compiler support for haxe.remoting

[Simn]

I've done 1-4. Currently blocked on 5 due to Java and C# having these HxObject classes that implement Dynamic.

[waneck]

I can fix that on the weekend

[haxiomic]

Another move: In js TypedArray classes should not be in js.html since they're part of es2015 rather than just browsers (having them in js.html is misleading when targeting node.js). js.typedarray could be a better place for them

Happy to do this as part of #7354

[Simn]

@waneck: Any chance you could look into this anytime soon? It blocks some progress.

[jgranick]

rename haxe.xml.Fast

Can we still consider a new name for Fast? Unless I am mistaken, the majority of Haxe developers use imports. As a result, var fast = new Fast (data); (or similar code) is confusing, where new Bytes, new Map and other cases still retain meaning.

Perhaps Haxe could use XML and XMLData to distinguish between simple XML data and the better "fast" access?

[Simn]

That's a more general discussion. For instance, we also haxe haxe.xml.Parser and haxe.xml.Printer which come with the same problem. I feel like this is alright in a world with decent IDE support.

[ncannasse]

I agree that "Fast" is not very well describing, maybe "Access" is better ? or another proposal ?

[Simn]

I'm fine with renaming Fast, just not for the reasons mentioned. Access sounds good.

[Simn]

P.S.: This is still blocked on the Java/C# HxObject problem @waneck

[jgranick]

It's more destructive, but there's also the idea of using Xml for the Fast API, and using Data or some other designation for the simpler one. It seems like Fast is the better user experience.

Map is a front end for different haxe.ds.* implementations, Fast feels like the XML front end to me.

[waneck]

@Simn Okay it didn't take a weekend, but here it is - https://github.com/waneck/haxe/tree/disable_implements

[Simn]

Wonderful, thank you!

[Simn]

implements Dynamic is kill

Last thing I'm gonna do here is rename haxe.xml.Fast to haxe.xml.Access with a deprecation-typedef.

We're keeping the haxe.remoting compiler support for now because I don't see how we could work around it easily.