LÖVE

tl;dr: Class Commons

As some of the guys in irc have probably seen, I want there to be a standard api for our class systems. Now, I understand it is not desirable for every class system to be the same, I mean, what would be the point in that? No, my goal is an api other libs can use. So, if you find yourself a lib that uses classes in some way, say a gamestate manager, you can use it with the class system of your choice.

Let's do an example Where in all these examples the gamestates lib is exactly the same, without any code changes.

Wouldn't this be awesome?

Now, of course there's a lot of stuff to discuss here, but first I want to know if there's interest in this, and whether the makers of various commonly used class libs are willing to work with me on this.

I set up a wiki page for this here: Class Commons.

If I didn't feature your class lib, sorry, I chose 4 I know of, and I can't make this a huge list, can I?
Also, if I did, but I butchered the syntax, again sorry, I did this after a quick glance at the examples.

So, you want to create a standard API that all class systems use, allowing all of those systems to interact with each other, at least the level of inheritance, correct? If so, that sounds pretty awesome, and I'd certainly be interested (though I don't exactly know how it'll work).

Sure! Do you have any implementation details in mind? A "speranto" for classes, as it were?

If that's the case, probably the first thing we should agree about is the "Greatest Common Divisor" for classes.

Here's my proposal for that:

Features that should be provided by the "common api" (IMHO):

• Single-class inheritance
• Constructors
• Instance methods
• Inherited instance methods
• Getting the class of an instance
• Getting the name of a class

Features I'm not sure about:

• instanceOf / subclassOf
• Getting the superclass of a class
• A "root" (Object) class
• Class methods
• Getting the list of methods from a class

Features I've intentionally left out (I don't think this should be part of the common api)

• Multiple inheritance - not all the libs provide that
• Mixins - not all the libs provide that
• Operator-related stuff - this includes __tostring; they are too tricky to handle correctly.

These lists are completely open for discussion. I don't know the other libs well enough, and some of this items have been put there only by gut feeling.

Yeah, I agree. I'm not sure about actually storing the name, though that shouldn't be hard, but we do need a name parameter, because it's easier to fake than to work around.

I was thinking perhaps we could do a 'single write', so you pass the full class in during instantiation and it can't be added to. Though this sounds limiting this is something we should be capable of getting everywhere. A, perhaps better, alternative to this is something like a class_start and a class_end, where the end function could be used to classify the table in case the class system needs defined, frozen, classes.

Other than that I pretty much agree with you.

Another thing I'm worrying about is the naming though, because of the various naming schemes all 'class' variants are probably out, but I guess we could do something like my example and use class-compat.

I set up a wiki page for this: Class Commons.

I am not sure I get this:

Do you want to

• create a new class system that has a well defined compatibility layer, or
• provide just that compatibility layer that the different class systems can use to convert between each other?

Anyway, both would be a good thing.

Kikitos core feature list sounds reasonable. I am not sure what you mean with "inherited instance methods" though. Isn't that contained in inheritance already?

vrld wrote:Isn't that contained in inheritance already?

Kinda. I meant not just "inheriting methods from superclasses" but also "being able to override inherited methods"; Maybe I should have called it "simple polymorphism". I wrote it late at night.

vrld wrote:I am not sure I get this:

Do you want to

• create a new class system that has a well defined compatibility layer, or
• provide just that compatibility layer that the different class systems can use to convert between each other?

I want a common API implemented as a compat layer for each participating class system that the libraries then use. So they call this common interface, but in fact they use that project's class system.

(So, creating a class via that api actually creates a class using, say, middleclass, if that is what you're using in your project.)

While this isn't exactly converting, it's more of the second than the first.

EDIT: I don't know if you've ever heard of it, but it's kind of like MPRIS, where the class system exports the MPRIS interface and the 3rd party lib is an MPRIS client.

I imagine it useful if you want to write a game using FooLib and BarLib, but FooLib uses MiddleClass and BarLib uses SECS, and you don't want to include both. If one of them was written using this API, then you could just use the class system used by the other library.

Well, both would have to use this API, but it means that we could use, for example, hump's gamestate manager with MiddleClass. (not sure how hump's gamestate manager works, so don't pin me on this!)