Sooo, again, my project Lite Foundation... But this time, its completely rewritten from scratch to be way more easy to use and better extendable. The single parts that make up the whole packet are better separated and everything should be much more accessible.
Long story short; Everything is better than ever, although incompatible with the older versions... sorry about that.

If you are new to Lite Foundation, let me give you a short overview:
Lite Foundation is written in C with the purpose to extend C with the concept of classes, delegated protocols and all this fancy object oriented stuff, all in a way that allows it to easily create class instances and classes. It also introduces a reference counting environment on top of the classes system, this means that you don't have to bother with the "when to free what" question anymore!
Every class instance has a reference counter, the so called retain count. You can retain and release instances. Retaining is like telling Lite Foundation "Hey, I want this object, please don't free it", it will increment the retain count by one. Releasing is like telling "Alright, thanks for holding this object in memory, but you can free it now!", it will decrement the counter by one.
If the retain count of an object hits zero, Lite Foundation will take care of freeing its memory so you can work headache free with memory allocations!

Of course, just having this is doesn't help much as one had to implement every class that one is interested in, thus Lite Foundation also has a standard library with common used classes that you can use right away in any project.


Now remark: This is just a "beta" release so that you can play with it and give me feedback, only a fraction of the standard library is currently implemented as it was not my main focus for this release. But there will come a lot more in the future! Also; The runtime code might be subject to change, I'll try my best to not break anything.



Currently implemented is a very powerful string class (way more powerful than Lite-C STRING object), a scanner class that can be used to parse/scan through strings, a autorelease pool class and a character set class (which is used by strings and scanners).
This is imo enough to give you a taste of what is possible and what might come in the future!

The current release also contains a getting started guide that introduces you to everything you need to know about Lite Foundation and a runtime documentation which helps you to understand how Lite Foundation works internally and how to extend it.
There are also two examples on how to use strings and scanners plus a reference that documents every function, struct and type that comes with Lite Foundation.

As always, everything is released under the MIT license!
You can grab your copy here (always the latest version)
Or just read the reference, or the Getting Started guide, or the Runtime Guide.

If you have any questions, please aks! I'm not good at explaining and Lite Foundation is probably a bit more complicated than the normal Gamestudio stuff. I tried my best to make the beginning as easy as possible, but if I forgot to cover a part that you don't understand: Ask!
I'm open for C&C, feature requests, enhancement requests etc.

People who always cried for classes support in Lite-C should have a wild party in this thread, so I wonder why it seems that nobody really cares...

However, Sid invested a lot of his precious time for an implementation of what people (should have) missed in Lite-C when working on big projects.
So, at least, every serious GS user who plans to develop more than a simple casual game should support Sid´s work most urgently.

I think i will make in bad mood people , but here is my
personnal taste !
The Class at final only represents something containing Methods and Variables ! If you don't use inheritence you won't win a lot !
If you use "include files (.h)" that contains also variables, methods, it can be similar in some ways to a Class !

--------

I don't see interest of making Class system in a script language !
The script is meaned to go fast and simple and easy for newbbies or 3D artist, that i think don't wan't to understand
all Classes and all Object Oriented Stuff !


It's the way some engine works like Unity offering 2 solutions :
- no Classes with script language
For newbbies, 3D artists , people wanting to go fast
- Classes with C#
for programmers, advanced people etc ...

So won't it be more simple to use C# directly with A8 no ?

It's only my personnal taste !

I stop here, i don't say it's a bad idea at all !
Perhaps some people will find it usefull indeed, perhaps it's
the next evolution of Lite C ??

Well, class might be the wrong name, but give me a better one. Its certainly not just a struct and not just a lot of functions but something that combines both.

About the inheritance, you can do this in Lite Foundation too, you can even build class clusters that use a proxy object to present a standard interface to work with the objects, you can also implement classes that can turn into faults and such things.
But I see that there is no way for class to name its superclass, I will add such a thing into the next runtime update so that classes can pose as other classes.

EDIT: Actually, you WIN a lot even without inheritance, you get the whole reference counting environment and lots of other nice things for free. Eg. you can ask _ANY_ Lite Foundation object for its hash or if its equal to something without inheriting from anything at all.


Certainly no, thats not a OOP approach as you can't create instances of the .h file or so, so you have just the one instance and thats it.



Luckily, Lite-C can be compiled into directly executable binaries, so why compare it with a scripting language? If you want to gain more power on a high level way, you can use Lite Foundations runtime and leave the whole standard library out, its certainly simpler than doing all this stuff by yourself, especially as a 3D artist or newbie.

EDIT; If you don't want to code a line as 3D artist thats just fine but then you either have a programmer that will do this for you or you don't use Gamestudio.



Sure, people who like C# might get the better deal by using it. But although the name Lite Foundation implies that its only for Lite-C, its certainly not developed for Lite-C (just look into the scripts and the whole #ifdef's that are inserted just to support Lite-C). However, it is developed to serve as a foundation for my Kernel project which is just C and I hate C# so its the better tradeoff for me. And as I'm a nice person, I took the time to port it so it can also be compiled with Lite-C


No, its for sure not a evolution of the language as it doesn't extend the language or changes the compiler or anything like this. Its just a bit of code!

excited to try it

Great
Please give me feedback what you think needs to be handled better, because there are certainly a few rough edges but without feedback I won't be able to clean them and the problem with rough edges in API is that it gets deprecated pretty soon which is really not what I want in a library that has "foundation" in its title

Hi Sid,

having a short look at this - without trying it out - two statements come to my mind.

a)
Great work, very impressive.
b)
I didn't get the purpose of this concept.

E.g. OOP makes live easy because a developer does not need to deal with the internals of a class. Is this also true for Lite Foundation?

E.g. inheritance - how would this example (pseudo code) look in Lite Foundation?


My first impression is that this is more a container (how I would call it) concept then OOP.
I think it would help to better get the purpose of this library if you could give some easy to understand examples which show for which problems this is an efficient solution.
So to repeat my first statements with different words:
Looks quite impressive, but as long as I don't see the benefit I would not invest much time to really understand the concept.

Hi Schubido,

about your first question, yes, one does not have to deal with the internals of a class. In many cases its even dangerous because chances are that a classes internal layout changes in the future. Eg. the string class (LFString.c and LFString.h) will be in the future changed to support UTF-8 and some other encodings, depending on the layout of the class will definitely break code in the future. However, just working with the methods won't break as they are maintained by the same person who also maintains the struct around the object.

Your second example is a bit more complex to answer as Lite Foundation gives you three ways to do this particular example;
First of all there is some boilerplate code to create the two classes:


So, now about how to implement the functionality, the first option is to use Lite-C's function overloading and breaking the code on all C compilers.
The second option is to use one function that accepts the polymorphic LFTypeRef and then does its work depending on what object it works with:


Not the best way either, but, you can still fallback to protocols. A protocol is just a definition of a function that must be implemented by classes that implement the protocol. The calculate function would then become a wrapper to a runtime call that then dispatches the classes protocol information and picks the right function which is then called:



There is a little more code needed to create the actual protocol, but that should give you an idea on how to do it. This is for sure not as elegant as a C++ or Java class but mostly because of limitations in the language which I sadly just can't fix.



Well, first of all; You can do real OOP with Lite Foundation!
I agree with the example problem, but I can't think of any easy to understand examples, for example I could write a example that shows how a class can implement faulting to help keeping the memory footprint low, however, this would assume that everyone understands the concept of faulting.
The same goes with eg. a example for class clusters, they are meant to float as fragments in the code, so it becomes more complicated to explain which part is what and how it works with the rest.

I wrote examples for the standard library that also ships with Lite Foundation for people who don't want to use the runtime directly, this is where the purpose of the library changes completely again. And as more classes get added to the default library, there will come more examples on how to use them (beside that the naming convention should make this really clear).

The runtime guide covers this part (how to extend it, how to work with protocols etc), but it contains not so much example code that can be directly executed.

Okay, Schubido's post inspired me to work on a better inheritance system and I'm pleased to announce that Lite Foundation has now a real single inheritance system

Classes can define a super class in their description and the runtime will try to fallback to the superclass wherever possible. For example, asking if an object is kind of a certain class (LFIsTypeOf()) will now return true even if the object just inherited from the object or an object that inherited from it (or deeper).
Same goes for things like LFHash() and something useful if you want to build subclasses; The dealloc and init callbacks are now called for every class in the inheritance chain.
This means that a subclass doesn't need to initialize its superclasses member but just its own new, likewise, on de-allocation, the class only needs to worry about its own allocations.

Also; All protocol functions will now be called on the super class if the objects class doesn't implement the protocol or you can call the superclasses implementation directly via a few new functions.


Another nice thing for people who don't care about the runtime and this nasty stuff: I'm currently working on a set class that can store objects in unsorted order, once I've done this, I will make a pretty cool and even useful demo to show what a few lines with Lite Foundation can do. So stay tuned

staying tuned.