Version 2.0.0 #18
TenebrisNoctua
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Release Version 2.0.0
Here we are! After more than 7 months, 2.0.0 is finally here. With the general release of the new type solver, Class++ 2.0 feels finally ready to be released.
I would like to thank everyone who used Class++, reported bugs, and sent feedback. Without them, I wouldn't be able to make Class++ as good as it is now. Feel free to make more bug reports if you encounter them!
Below is a general change-log of everything from the new type solver beta releases to this release. There are lots of things that you need to know about.
Changes from 1.2.1
@selfalias with require-by-string in the modules.objectwill now have auto-completion for certain default methods.class.extendsmethod and instead merged the functionality with theclassfunction of the main API.super().object, which allows you to access parent class methods from child classes.Type.typeof()andType.typeofClass()methods have been replaced withType.type()andType.typeof()methods that are more compatible and consistent with Luau's built-intype()andtypeof()functions. You can even replace these built-in methods with Class++'s Type API, and your code will still work!classDatatable.class.newnow reflects the parameter types of the definedconstructorfunction in theclassDatatable. This also includes inherited classes.falsein theclassDatatable, Class++ will now show it asany, instead ofboolean. This is to reduce type errors when first defining members in theclassDatatable. (You can go around this by casting or annotating it tobooleanlater.):Destroy()method, the internalobjectDatawill properly be disposed of. (Recommended)destructor(if it exists) will be called with a copy of theobjectData. This is to ensure backwards compatibility, and to make this system properly work. The copyobjectDatashould never be held onto, as afterdestructorruns it will immediately be disposed of.autoObjectDestructionproperty of the main API.destructorfunctions will now emit a non-fatal error from Class++ when an error occurs in the function.autoObjectDestructionis disabled)Destroy()can no longer be called within constructors.RBXScriptConnectionsinside objects, alongsideInstances.classDatarestrictions.This discussion was created from the release Version 2.0.0.
All reactions