PureBasic Forums - English

Purebasic can handle standard objects (interfaces) very well. It is the same effort as with 'C' (not C++).

Initializing and calling interfaces and creating own interfaces ('IUnknown' and 'IDispatch').
See ActiveScript. Link: viewtopic.php?f=12&t=71399

Modules as object with standard interface 'IUnknown'
See OOP-BaseClass. Link: viewtopic.php?f=12&t=64305

Rinzwind wrote:Of course you can create code generators (which is what is meant with “tool menu” I guess?) but thats not a solution, just a hacky workaround.

Absolutely not. Just my english is such a shit that I am sure you won't never understand me...

Yes Im aware of the solutions involving interfaces combined with structures and data sections. It is a (useful) hack, not very programmer friendly. Its workable when one really needs it and I guess imaginative but too much hassle to be generally picked. Would be nice if the interface keyword supports all needed parts: data and procedures and maybe even constructor/destructor or init/finish to use pb terms. But that would be a better fit to a new class keyword.

Imho

The first post at least put things reasonably simple and flexible together but alas problems with nested structures. Dont really understand why we can not define procedures with an automatic me/this variable in a structure. A little bit more support for optional oop cases has been requested a couple of dozen times during a decade. Helps immensily with code structure and doesnt mean that youre not programming procedurally. But then again array and structure initialization is also stil a pita. array1.s("hello", "world") struct1.Car("hyundai", 2015, 3)

Stay dreaming thanks for the feedback.

My thought is use PB for its strengths. Preprocessors/Macros to emulate OOP do show initiative, but depart from the spirit.
I know it seems old fashioned, but mylib_SomeFunc() works fabulously and amalgamates to a single file. Big, but simple.

Programming with interfaces is not emulation but real object programming.
Even the PB-IDE partly uses object oriented programming.

Here is the difference to make between object oriented programming language (which PB is not) and object oriented programming. (What goes with PB)

I also don't want to have an object oriented Purebasic version. The current support is quite sufficient for me.
I like procedure oriented programming better, but sometimes it works better with objects.

There is a free to use macro toolkit for fasm allowing full oop: https://fresh.flatassembler.net/index.c ... /4_oop.txt
Probably the easiest route if PB ever wants to support full oop, i personally dont really need it - im fine with objects and interfaces.

I only say "emulate" because there is no "class" keyword, among others, in PB. And the use of macros points to omissions in any language. It is a catchall to minimize the depth of a language. Ironic, because their use leads to more complex syntax.

Indeed Skywalk. Increases complexity because “refusal” to add a few little syntax helpers. Function support in a Structure would help those seeking “object-like” behavior in a very simple (BASIC) way. It matches PureBasic style nicely and can be elegantly and easily implemented without breaking anything (its basically function pointers and one structure pointer), so quite disappointing to still not see it happen. Hope for the best.

The Interface is just one part of oop, a description of delivered functions by an “object”. Nothing else. It doesnt help the programmer actually achieving that. You need other parts for that too if you go that route, hence the class keyword. But I would stay with KISS structure enhancement. Agree Fred? We have a feature request forum for a reason. But nothing is done with the results it seems.

Anyway if anyone has a fix (same style) for the nested structure this-pointer problem...

Rinzwind wrote:...
Anyway if anyone has a fix (same style) for the nested structure this-pointer problem...

Have a fixed spot for the vtable pointer it has to be at the same spot regardless of the objects content.
Objects can also be easily modified at runtime - if needed use an array as vtable to add and remove entire functions.
Its also easy to define several functions for a single function pointer (polymorphism nonsense) but u will always need a way to decide which function to use.

Rinzwind wrote:Anyway if anyone has a fix (same style) for the nested structure this-pointer problem...

Can you modify your example to print what you expect vs what you get? The problem is not jumping out to me?

The last output of the code is\
expected: p1\r1 : 101 201 80 40
debug *r: 1 1 101 201
debug this\r1 : 101 201 80 40
Rectangle 1 1 101 201
Circle 1 1 101

p1\r1 : 101 201 80 40
Those are indeed the values of rectangle r1 in painting p1, but when accessed with p1\r1\Draw() the *this pointer in the rectangle draw's procedure (via that ASM line) we do not get those values, but the values of the root structure (painting p1). The root structure is a Painting. I 'cast' it to a rectangle (*r in _PaintingDraw() which is technically invalid), and we see that those values match those wrong values. That is just added to see where the wrong values 1 1 101 201 are coming from.

To pin point the issue add following lines at the end: output:
Rectangle 101 201 80 40 (correct)
Rectangle 1 1 101 201 (incorrect)

The ASM macro always returns the root structure it seems.

You did not create a new object by only referring to a pointer.
You have to instantiate with your NEW() or CREATE() function.

Nope, otherwise asking directly for it would not give the correct result but a memory error. Also every test would error out if that was the case. Its a structure in a structure, not a pointer to a structure. So it is already initialized.
The problem is that the asm that gets *thia doesnt handle layered references.

Define *pr.Rectangle = p1\r1
A *pr\Draw()
B p1\r1\Draw()

A works fine which just is a pointer to the same r1. B not, p1 stays in the rbp register when in procedure Draw, not r1. At least thats what is happening. Probably makes sense if one knows asm. I dont...

Ok, your case is nested, so you can go back to direct pass of This to the methods.
Procedure _ShapeMoveBy(*this.Shape, dx, dy)
*this\x + dx
*this\y + dy
EndProcedure

You don't get to use the Macro(), but it is a workaround until you decide on going with Interface and vtable or find a newer ASM GetCaller().
Or you can create single level objects.

Mijikai wrote:There is a free to use macro toolkit for fasm allowing full oop: https://fresh.flatassembler.net/index.c ... /4_oop.txt
Probably the easiest route if PB ever wants to support full oop, i personally dont really need it - im fine with objects and interfaces.

Thank you for this clever research !