Class++ | Classes and OOP made easy and powerful with Access Specifiers, function overloading and more!

Resources Community Resources
, , , ,
#29

Release 1.0.1

  • Members of Friend Access Specifier no longer replicate to the objects as they’re only used within the class object itself.
  • Updated the documentation.
1 Like
#30

Release 1.1.0

  • Class++ objects now support type checking! This was an update that I was planning to do for a very long time, and it would not have been possible without @HugeCoolboy2007.
    • All of the created objects should now have type completion for the members stored in the Public access specifier.
    • Creating custom types is no longer needed, however, if you still want to use the full features of type checking in Luau, it’s still recommended that you use custom types for your classes.
    • For more info, check out this documentation page.
  • Util and Type modules now fully support the class type.
  • Updated the documentation.

(@arbitiu turns out it was possible lol.)

4 Likes
#31

unluckiest timing :sob:, having released this barely a week ago

1 Like
#32

Well it’s still in beta, so I think I have plenty of time to fix things up, but I didn’t know it would be this broken :sob:

#33

My topic was somehow “moderated”, and I was saying that what you made is amazing and very underrated. Probably adding to my list.

2 Likes
Metatables And OOP: Simplified
#34

Quick update: Class++ should now support Wally and Rojo!
I will make some improvements over to it in the next few days, but it should work for now. Let me know if you encounter any issues!

Wally link:

Or add this to your wally.toml file: classpp = "tenebrisnoctua/classpp@1.1.2"

Also, the documentation has been updated with a new theme!

#35

Fixed some problems with the documentation and Wally, you should now be able to easily integrate Class++ with Wally and Rojo!

Also added a new link button on the main post for Wally.

2 Likes
#36

Does this API use metatables? If no at all, then this is great since metatables cannot be transferred between non-module scripts as well as between client and server

#37

Sorry, this API uses metatables. It has to because many features including Operator Overloading and Function Overloading needs to use metatables in order to function.

Though I understand your concern about metatables not being transferred over with RemoteEvents and RemoteFunctions to the Server or the Client, there are solutions such as a constructor that takes in a data table and recreates the object on the Server or the Client.

Generally OOP itself on Luau requires the usage of metatables, without them you lose a lot of power. This API functions almost the same as the Roblox Instance API, both create userdata objects with a metatable attached to them.

I hope this answers your question! If you have more, feel free to ask!

1 Like
#38

Oh, that’s actually sad. Although, the API looks really good. I should use it in my project, probably. Thank you for answer!

1 Like
#39

No problem! Metatables aren’t that bad actually, aside from the issue you mentioned above, the module is very well optimized! (In fact a version for the new type solver is in the works and will be released soon.)

1 Like
#40

will the syntax be changed when the new type solver is implemented?

And how does the constructor and destructor work? when you inherit a class?

does the base class calls the constructor then the derived class’s constructor? or the derived class’s constructor is only going to be called? or which ever is which.

#41

Not at all. The new solver is going to be implemented internally for the purpose of providing a better auto-type completion system for objects. Right now, it is enough for the most part, however, I want to make it so much better, and faster.

Currently, only the derived class’s constructor is called when you create a new object. This behavior will be changed with the new update to behave more like C++'s constructors.
(Parent class’s constructor is called first, then the child class constructor will be called next.)

#42

Hopefully the update is sooner!

I’ve been trying figure out why the constructor does not work as I expected it to be, It does call the constructor on the base class before the derived class but the function does not point any references to self on the base class and only on the derived class.

I was porting some of my Classes to Class++. Unfortunately this is not going to work.

Thanks for the info.

#43

Hmm… that might be a bug, can you create a bug report on the GitHub so I can get it solved ASAP? Sorry about the issue by the way. (You can also post the code you’re having trouble with as well.)

#44

Alright, turns out that was a bug and not intentional (base class’s constructor shouldn’t be called).
In the next update, the base class’s constructor will be called without problems, and bugs should be fixed.

1 Like
#45

I was wondreing about this API and came up with an idea. Why wouldn’t you add a function to transfer an object or class to the different side (client->server\server->client)? This would be such a great feature that will save some time and prevent people from re-inventing the wheel

#46

It’s pretty easy to sync the classes between different environments, an example would be is to create a module that creates a class inside it that can be required from both server and the client, and that class would have a function that takes in the data from different environments and creates an object through this data. All you would have to do is to setup the server-client connection through scripts.

#47

But still, if you implement this feature in your module, this would be a nice bonus

#48

I can’t really implement it to this module, but maybe in the future I can put a small template system inside the GitHub repo to make people’s lives easier.