Should I extend, or use pointers?

I have some code here where certain objects need to be very specifically customized, for example to pass particular parameters to particular functions. The natural assumption is to Extend their types, overriding the necessary methods.

However, there is something to complicate this: Only one single instance of that extending type would be created! Seems kind of a waste to define a whole new Type just to create a single new instance and forget about it.

The alternative way is to have stuff like a factory method that runs a callback function. This way, every instance is of the exact same Type and all of the customization is happening with callbacks.

(I hope that made some sense...)
I can't decide which way is the best way. One has global functions and pointers all over the place, the other has extended types that hardly do anything.

Extend.

I agree with FlameDuck. Extending the type would be a lot cleaner, and a hell of a lot easier to fix or change.

Extend.

It's perfectly okay to create a single instance of something. There's a whole concept for this called the Singleton Pattern. What you're doing might not really be a Singleton, but this illustrates that it is an accepted and encouraged practice. Always keep things modular.

The only problem with using the singleton pattern in Blitz, is that you can't have private constructors, so there really isn't a mechanism to ensure you only instance it once.

But it is possible to get it done.

Global variable in the type of the type itself. when you call the constructor function it either returns the content of this global variable or it creates the single instance of it, assigns it and returns it then.

Not that clean but doing a similar thing within new sadly isn't possible ...

Then it's decided!

I should have mentioned, though:
It's not me doing the customization of all these Types; setting up these methods is the main piece of a little system used throughout a big program. This crazy extending stuff is not under the hood, but part of the interface for people to tie actions with parts of existing code (opening up, in the end, a sort of event-oriented extension system).
So the thing that goes against extending as an interface is that it takes more writing; instead of just defining a function and tying it to a created Type you have to extend a type, set up its methods and create it. (Which feels like more, but upon reading that statement of mine I realize that it's about the same).
Hehe, that sounds stupid. Well, it is stupid :P

Hm, singleton pattern, eh? They have a name for everything! Quite reassuring. No problem with private constructors; there is a possibility that some idiot will want to use the same event object in multiple places, but it is very unlikely. I don't really want to stop them, as there's no reason to.

Still doesn't prevent you from creating as many instances as you want using new. A Singleton does.

Yes. Quite reassuring that people have solved most of the problems you're likely to encounter.

Oh yes to prevent the new approach there is a simple way just to mention it: put a throw "You are not allowed to create instances of this type in a different way than using the constructor XYZ" in and problem is "solved" ^^

Catch: they can handle it and know that they do shit
Not Catch: runtime error and dang

Yes, not the clean way. But unless we get a way to prevent creation of the object or reassign the resulting object within new, there is no cleaner way I fear ...

Method New()
RuntimeError "You idiot, I told you not to create this with New!"
End Method

There we are: Singleton Types :)

Cute - although that prevents you creating *any* instance. Instead...

Method New()
   Global instance:TWhatever
   If instance Throw "Oops!"
   instance=Self
End Method

Oh, that's clever. I tried Picklesworth's version a while ago, which as you said didn't quite work. Still. Private constructors, eh? :o>