Code optimization sugge

[guobinyong]

• Static members of classes are used heavily as namespaces (e.g., NullEngineOptions), which can be implemented using namespaces or objects; Not only does a class require more code to be written to define the type (e.g., public static readonly), but it also creates a function that wastes memory space;

• Static members of classes are used heavily to store constants of the same type (e.g., PointerEventTypes), which should be implemented using enum; In the case of PointerEventTypes, using classes can cause the following problems:

  • I can’t express the type exactly: I can only use number to express the PointerEventTypes type, and if I want to express the type exactly, I can only use the (typeof PointerEventTypes)[keyof (typeof PointerEventTypes)] method, which is very inconvenient;

  • Not only does a class require more code to be written to define the type (e.g., public static readonly), but it also creates a function that wastes memory space;

[sebavan]

@guobinyong

Static members of classes are used heavily as namespaces (e.g., NullEngineOptions), which can be implemented using namespaces or objects; Not only does a class require more code to be written to define the type (e.g., public static readonly), but it also creates a function that wastes memory space;

Not sure NullEngineOptions is a good example here as it is not a static member of anything ?

In this particular case, it is normally ever used once per app so not really a huge memory consumer and defining it as a class helps to define the default values (I would think it is why it is a class instead of a simple interface).

I agree going with an interface only in the future would help a microbit with parsing but we can not break back compatiblity for this.

@guobinyong

Static members of classes are used heavily to store constants of the same type (e.g., PointerEventTypes), which should be implemented using enum; In the case of PointerEventTypes, using classes can cause the following problems:

For the first point here is a temptative PR addressing it in a Back Compatible way Narrow numbers to const enums by ryantrem · Pull Request #14076 · BabylonJS/Babylon.js · GitHub

@guobinyong

Not only does a class require more code to be written to define the type (e.g., public static readonly), but it also creates a function that wastes memory space;

Agree and this can easily be replaced with an object in this case. Feel free to make a PR for this one.

Our rule of thumb in Babylon is to never break back compat except if we really see a tremendous gain and even yet we would try to add easy path for the users to move. I know it can sometimes be heavy but it is so awesome to move version in an easier way. A lot of our users are actually chosing Babylon for this specific purpose.

[Deltakosh]

Agreed with Seb. One philosophy is to protect back compatibility. This is not new

[jeremy-coleman]

babylon’s code guidelines says files should only export one class. I think its fairly obvious static class members are dumb, but back compat is more important. If you want slightly faster framework with breaking changes every six weeks with arbitrary api changes threejs is a great option also you can fix things like this with code transforms at build time;)

[sebavan]

@jeremy-coleman

slightly faster

Only by default cause with the correct config but yes I am totally biased

[guobinyong]

However, I’m looking forward to seeing when babylon can do a refactoring to get rid of compatibility and provide some more elegant, advanced code and design ideas, such as:

• ECS architecture;
• Type definition of the specification;
• All depth references that are repeated multiple times extract a local variable

Just like Vue, React, and Anglur, they have all undergone 3 architectural and design refactorings for more advanced design

If there is such a day, I would like to be part of this refactoring