Geometries: Move to ES6 classes.

[Mugen87]

Moves all geometry generators to ES6 classes.

One important note: It was necessary to refactor ParametricGeometries from the examples. It used to derive from ParametricGeometry via ParametricGeometry.call() which is not valid with ES6 classes anymore. The following small fiddle demonstrates this issue:

https://jsfiddle.net/w2xfb6eg/

All devs have to be aware of this language detail. Again, there will be no problem when using three.js or three.min.js. But consumers of three.module.js will have to upgrade their code to classes or add some sort of additional compilation step if they derive own classes from library entities via Function.prototype.call().

[Mugen87]

I realize right now that a lot of example code needs to be converted to classes during this process. For instance as soon as THREE.Loader becomes a class, all example loaders have to be adjusted, too. Oh dear!

[gkjohnson]

as soon as THREE.Loader becomes a class, all example loaders have to be adjusted, too.

If this is a concern then maybe the buble transformation can be applied to the three.module.js output, as well, until we're ready to migrate the examples to classes? The output from buble looks like it would be compatible with the current inheritance practice. That way the migration of core to classes can continue without worrying about breaking examples for now.

[Mugen87]

I'm fine with that. Although I think the transition in the examples folder is definitely manageable. It will just take a little bit more time.

TBH, my comment was not intended to question the migration itself 😅. I think it's important to go that way. We just have to be aware about the consequences.

[gkjohnson]

TBH, my comment was not intended to question the migration itself 😅. I think it's important to go that way. We just have to be aware about the consequences.

Oh yeah! I think it's great we're moving to classes. I just mean to suggest that if the migration of the examples is disagreeable for whatever reason that this could be a solution / stopgap.

[PerspectivesLab]

Hi ! do you know a time frame when this will be merged ? thx !

[Mugen87]

@mrdoob Is it okay to move on with the class migration?

[PerspectivesLab]

@mrdoob Is it okay to move on with the class migration?

thx mugen87 !

[donmccurdy]

@Mugen87 note that your JSFiddle could also be fixed with the somewhat easier change to Geometry.constructor.call( this );. I think moving to ES6 classes is a good direction for the project, but if that saves time on examples while we focus on the core library I'm fine with that too. :)

[Mugen87]

That's great! I was not aware of the usage of constructor. Well, in this case I would focus on core first and then migrate the examples.

[Mugen87]

Um, I've directly tried the constructor approach in ParametricGeoemtries but get this error:

I've just copied over the latest code of ParametricGeometries to my branch (so it uses no classes) and added the mentioned line of code for THREE.ParametricGeometries.TubeGeometry, THREE.ParametricGeometries.SphereGeometry and THREE.ParametricGeometries.PlaneGeometry.
E.g.

THREE.ParametricGeometry.constructor.call( this, ParametricTube, segments, segmentsRadius );

[donmccurdy]

@Mugen87 Hm, you're right. My suggestion runs in that Fiddle, because Geometry.constructor is just Function, not the actual constructor. We won't be able to extend ES6 classes unless (a) the parent class is transpiled, or (b) the child class is an ES6 class too. See https://stackoverflow.com/a/51860850/1314762.

Unless we want to transpile all classes (for both the module and commonjs builds) during the migration, sounds like we'll need to start with examples/js first? Or save objects likely to be subclassed, like Mesh, Object3D, and Geometry, for last?

[DefinitelyMaybe]

Aha! found this PR. Will look into the scripts and see if I can do a similar thing with one of the smaller folders.

[Mugen87]

Closing this for now. Let's proceed with ES6 classes next year when examples/js is gone.