>>You might consider returning .f. from form.load in abstract forms, so it's abstract or concrete controls won't even init().
>
>I was already on the verge of commenting on the usefulsness of returning .f. in the container's init after the contained objects init may have done dastardly deeds.

That's why I thought about form load(). But that is not ideal, true. You would need to add the requirement, that at init() an abstract class should not do anything else, than decide if it instanciates or not. You would need to define a secondary init() called by the parent container, if that container class instanciates. Then it would be working, preventing things to run too early.

I see putting an abstract button on an abstract form as a valid way to compose some class, so I don't see the point to forbid that.

I see it's a problem to add an abstact button at runtime and it would instanciate because of it's parentship only. That makes my Vartype(This.Parent) check invalid, true. Reverting back to the Class check only, that prevents to use such buttons this way. Then you would have the need to subclass such buttons before even using them on an abstract form.

So there you have the answer on the initial question, you'd need to subclass an abstract button as a concrete one before using it. Peter then i making a mistake using abstract buttons or editboxes on his forms. I still see composing an abstract form with abstract controls a valid approach, but as the containership check is not valid, you would have no way to ever instanciate even concret subclasses of such forms, if you implement the Class name check. So you would be forced to subclass.


Moving away from the form/button example to patterns, let's look at the abstract factory. You should only instanciate a concrete factory, not an abstract one.

But you might design an abstract factory to have some methods implemented, which work for all concrete factories you plan to implement. And at it's init you'd pass a parameter, from which that abstract factory decides what concrete factory it adds to itself and maybe then binds it's own methods to the concrete factory subobject. Now would that kind of abstract factory really be an abstract factory? It's not having the concrete methods, but it's composing it's runtime version to be a concrete factory. Then it would be it's own interface or adapter.

I think Peter has such abstract classes in mind, as he seems to want to dynamically decide when an object gets concrete. My way of the class check won't allow such class designs. I don't see that as a problem.

Bye, Olaf.