PureBasic Forums - English

@fsw: nice idea!

I don't like that SelfType concept. It seems backwards
and is exactly what you shouldn't have to do with OOP.

The Syntax is not necessarily bad (i.e. having functions outside of their class),
though some association is required if you have two methods with the same name.

Of course the number of features is open-ended, but here are the ones I'd like to see
that I regard as the bare minimum for any language that claims to support OOP (in one way or another):

• Ability to define classes or objects in general (preferably with Class / EndClass)
• Single Inheritance
• Member visibility, Public, Private and preferably Protected
• Constructors / Destructors
• In case of PB, the ability to create objects on both stack and heap.

Regarding inheritance, I'd even be fine with pure virtual classes (same behavior like using interfaces).

@Shield
I understand what you are saying.

However, Fred and Freak always stated that "true" OOP will not be implemented.
And I understand that position; especially after seeing some C++ OOP code done in the worst horrible way...
FreeBASIC is BASIC with added OOP implementation, the syntax they created has the C++ influence.
IMHO it's overly verbose and overly complicated (however, it gets the job done).

Newer OOP programming languages like Swift do away with the old way of OOP syntax.
Which IMHO is a good thing as I prefer the KISS principle.

We all know that sometimes we don't get what we want, therefore we have to scale down our wish list.

IMHO what I suggested (implementing OOP capabilities following the Go way) is a more reachable goal.
Especially for a procedural programming language like PureBasic.

Thanks for reading.

The problem is, the more "Basic" (no pun ) you get, the more useless it becomes.
You can't create well designed OO programs without the first four features I mentioned above.

Since PB won't go the OOP path anyway, it makes more sense to talk about implementing some features from the OO world
that can also be applied to the procedural realm. The problem is imo that PB's syntax is quite restrictive when it comes to
more advanced concepts. For example, I'd really welcome function overloading but that would be difficult to implement due to the way
how PB treats types (since PB is not really typesafe).

New languages like swift are mostly just new implementations of long existing and elaborated concepts. It doesn't happen very often
that a language or a concept is truly innovative. Most of the new ones are usually rather short-lived, with only a few being strong enough
to push through and become more or less popular (of course that's easier when you have a huge-ass company behind it).

Speaking of that, I think we're going to see some pretty amazing things regarding .NET, now that Microsoft has become more generous
with this technology, with languages and platforms being one hell of a lot more compatible with each other.

Anyway, to get back to PB and to summon some thoughts, I 'd like to see some of these (non OO-related) features (in no particular order
without any hope of them ever getting implemented ):

• Function Overloading (at least for different argument numbers).
• With the above, some kind of templating mechanism.
• References.
• Generally better type safety (probably something like EnableTypeSafety).
  and proper cast mechanisms.
• Anonymous functions / lambdas.
• Try / Catch and exceptions for better error handling.

Pretty much, from the top of my head...


Cheers.

I think function overloading and templates would be the two most useful to have while being the less problematic for the compiler (even if templates are not trivial).

Overloading alone could mitigate the absence of templates at least a bit.

Both would be very useful in writing code much cleaner and easy to read (especially libraries able to work with any data type).

I had proposed a possible simple way for overloading here -> http://www.purebasic.fr/english/viewtop ... 33#p417233

Yes, overloading would be awesome to work with complex numbers and not having to write DoThisD(), DoThisL(), DoThisCmplx(), DoThisB() Procedures...

Fred wrote:Not everybody wants OOP, and PB won't have a OOP built-in, it's a design choice and I have made it clear a lot of time on this forum. If you don't like it, do as Shield did, find a tool which fits your needs better.

That's what it boils down to.