Epic Fail, more like
The source is still available
here.
And yes, I'm still here, haha
I just dropped by to see if PureBasic was still happening - many years later, and still no OOP, so I guess that's pretty definitive.
I have worked with numerous other programming languages over the years, and I have just one new thing to bring to the table - take it or leave it.
As I have argued in the past, you
have objects in PB: Structures are essentially objects without methods. My view on that has not changed.
As we also debated in the past, the concept of object-oriented programming is applicable to any language, including PB - it just isn't very practical (and the resulting code not very maintainable) without any native syntax to support it. I stand by that as well.
I did not know much about pure functional languages back when this discussion started - I took an interested in purely functional languages when they started having a renaissance these past years, and some exciting new functional languages popped up in the landscape, and quickly noticed some key differences between these languages and what I had heard described in the past as "functional" languages.
PureBasic is not a pure functional language.
Now, before flames start coming out of your eyes again, let's get our terminology straight here
PB relies on mutable state, in the form of mutable variables. By definition, that makes it an imperative language - an altogether different family of languages from functional languages.
Most object oriented languages are imperative, so PureBasic belongs to the same family as most mainstream OO languages - and not to the family of pure functional languages. PureBasic may be "pure something", but purely functional, it is not.
In my opinion, any imperative program by definition is going to contain some aspects of object orientation, because what is object orientation really, at a fundamental level, if not a conceptual model to help encapsulate and manage state? Of course in actual language implementations, it's more than that, but the OO concept is truly just a mental model.
Well, you have mutable variables and Structures and you manage their state, so you're using OO concepts already - with or without keywords such as "Object" appearing in your source-code. You even have Interfaces in PB now, which means you have inheritance - a classic object-oriented concept.
One practice I have learned and embraced over the years, while doing web-development, is that of pure models and service-oriented architecture - essentially, using classes with no (or few) actual methods to model the business domain. The actual methods go into separate classes (called "services") which have no (or little) state. Ironically, this gives you (almost, not quite) the same kind of separation you are forced to have in imperative non-OO languages such as PB.
Our worlds, then, are not really very different from each other at all. We both have to manage the state of variables and records. We both practice separation of state from functionality.
To summarize: in OO land, we use model-classes, in PB land we use records (Structures). In OO land, we use service-classes, in PB land we use functions. (and recently namespaces, aka Modules.)
It may surprise you then, that I am not here to make another attempt at selling you on the idea of OO in PB.
Instead, I would like to introduce you to
C# Extension Methods.
Ignore for a moment the fact that C# is an object-oriented language, and forget for a minute that extension methods in C# also happen to work with classes.
What should make you curious, is the fact that extension methods also work with structs, which are mutable records - the equivalent of Structures in PB. (and they also work with Interfaces.)
Extension methods are static methods, or in other words - an abstract class (containing only static extension methods) is the equivalent of a namespace (a Module in PB), and the extension methods are the equivalent of functions in a namespace. In C#, they happen to be defined using the class keyword, but an abstract class that contains only static extension methods is not a class you can use to construct objects - in other words, it has nothing to do with object orientation per se.
Calls to extension methods may
look like class method-calls, but this is in fact just syntactic sugar for static method-calls.
The beauty of this, is that you can avoid redundant repeated references, in your source-code, to the container (class, namespace or Module) where a collection of static methods happens to be defined.
In other words,
actually literally means
Code: Select all
ParticleOperations.move(particle, 0.5, 1.8)
and compiles to the exact same code. The compiler just has to do a little extra work at compile-time to locate an included compatible move-function.
You can avoid repeating the name ParticleOperations in your source-code, in every function-call - and instead just import it once, at the top of the file. Another recent language from Google called Go
uses this approach and perhaps more correctly actually literally calls them "method sets".
It is slightly more work for the compiler to resolve the function-call at compile-time, but there is no run-time penalty - no memory overhead from maintaining method-tables, and no computational overhead from resolving function-names.
So effectively, extension methods remove the need to restate your assumptions with every function-call - they make the source-code simpler and easier to read by removing a lot of duplicate semantics, and in turn this makes the source-code easier to maintain.
Never mind what the syntax would look like, for now, that's besides the point.
If you could have those benefits, without introducing the Object or Class keywords, constructors, destructors, or any number of more complicated OO concepts that seem to make some people break out in hives - would you be interested or more open to that?
Or is there perhaps already an equivalent feature in PB by now that I missed?
Or were you hoping I was dead, and currently wishing I would never come back?
