Creating Components - How am I doing?

[GedB]

Axend,

1) The problem with your approach is that the function can only create one instance, since there is only one shared variable. Unless I am missing something, you have created a singleton.

I have moved on from using a linked list because it polutes the global namespace. If objects are to form a library and be generally included in other codes then the global namespace becomes a precious resource. For this reason in my stack example I allocate the memory directly rather than using a linked list.
viewtopic.php?t=10319&start=15

I've been pushing Fred for anonymous functions to avoid having to have function names in the global namespace, but he doesn't like the idea.

viewtopic.php?t=10372&highlight=global+namespace+ruby

2) I prefer structures because there definition tells you what it is, which an Array does not.

I think that

VTPBFriendlyFunctions(0) = @get_Name()

is less clear than

VTPBFriendly_vTable\get_name = @get_Name()

The array version could be improved if you used a constant rather than an explicit 0, but why bother when you have structures available?

Also, structures now support the same inheritance features as interfaces.

Having the vTable as a global variable is actually an advantage, since the one vTable is shared between all instances. The vTable doesn't have to be global anymore. You can just have it as a static variable in the creation function. Arrays, on the other hand, are always global.

3) Personally I prefer the use of a creation function. I hate the whole use of IIDs in COM because it is just so complicated and a single point of failure which so often fails.

I take the lead for creation functions from the Eiffel language. So much clearer, with no need for all those complicated mechanisms.

Knowing the name of the function is no more difficult than knowing the Prog ID, and a lot easier than knowing the GUIDs. Like Eiffel, you can have several creation procdures. For example, a com object might have

COM_Create_From_Binary_IID(IID.guid)
COM_Create_From_String_IID(IID.s)
COM_Create_From_ProgID(ProgID.s)
COM_Create_From_Unicode_ProgID(*ProgID_buffer)

So much clearer than using operator overloading, especially if you have an autocompleting editor like jaPBe. Note that two of the procedures take a string argument.

If the object was packaged in a library then all the user would need is the interface definition and these creation procedure names. No need to register or any other runtime burden.

If you want to have objects provided at runtime then simply put them in a dll, only the creation functions need exporting.

Of coure, all these are just my own religous beliefs. I am stating the reasons for my personal choices. YMMV.

[aXend]

@GedB:

Thanks for your explanation.
1. About the singleton: You are right, I overlooked that. About support for OOP in PB: I have the impression that it is not very popular in the PB community. What do you think?

2. I think this is a matter of taste. It both works. I don't like it to get lists of names. May be a PB variant of MIDL would solve this. Define your interface and your implementation and then glue it all together.

3. Your approach is clear. I agree it has advantages. And COM IS complicated. I still have a question about compatibility. Defining a OOP approach for PB is nice, but it stands alone. Only to be used from PB. I would like it to have PB functions available from e.g. Javascript.

@Danilo:

Thanks for your examples. I had seen an old one before (with CallCom), but I didn't see all this together. Very nice
I like the example with the OCX, but I found that is not general applicable. It crashes when I close the window and also if I apply it with another OCX. Working with Interfaces and ActiveX has become easy now, but when it comes to visible components, it's not that clear yet (for me that is).
The OOP examples still look much like the ones from GedB (gladly), but they're more in-sync with COM rules, where think that GedB is heading for a different approach.
Is it possible to write COM from PB?

[fsw]

@Danilo,
looking at your examples I can see that one example (OOP.pb) is the one that was once delivered with a PureBasic BETA - so you are the creator of it...
There was no name at the top of the example delivered with the beta.

BTW: thanks very much for this, it got me started using oop with PureBasic.

One thing I found out looking at the examples of yours:
Your Taskbar2 example doesn't work 100% as expected. If you have several TABs in the taskbar and call your example all is fine, but if you work with another app (get's the FOCUS) and you activate (set the FOCUS) back to the example file, the TAB shows up...

[GedB]

3. Your approach is clear. I agree it has advantages. And COM IS complicated. I still have a question about compatibility. Defining a OOP approach for PB is nice, but it stands alone. Only to be used from PB. I would like it to have PB functions available from e.g. Javascript.

Ah, but this is exactly what I want to do. To define an OOP approach that is purely PB. No dependancies, no extra overhead. Nice and neat.

I would love to make PB work nicely with COM, and I spent quite some time trying, but I'm afraid I don't have the apptitude for it. I certainly wasn't able to make the progress that you have done.

Hopefully our two approaches can compliment each other. For example, creating objects to wrap all the complexity of dealing with GUIDs, ProgIDs, Unicode, Automation, BSTRs, VARARRAYS and all the rest of it.

[aXend]

Hopefully our two approaches can compliment each other.

Let's go for it!