Changing the type of class at runtime

Even if it could be done, it sure looks like bad practice.
I suggest you use a property that can be changed in runtime, to make your object's behavior change according to your needs.

Well, if you have a lot of differences between TFirst and TSecond, it makes sense to not having a complicated TFirst object just in case a property 'Type' changes from typFirst to typSecond
I certainly would not mark this kind of work as 'not proper' or 'bad practice', it very much depends on the use case.

add a method or two like :

procedure TFirst.Assign(tf:TFirst);  // Copy all TFirst fields from one instance to the other. Maybe override it in TSecond if you have some other initializations to make when TSecond get content from TFirst

constructor TSecond(tf:TFirst); // Will essentially call Assign

For those who are not yet sure that this is not a bad practice, here are the advantages :
- why reserving a lot of memory when you only need a few properties when the object is on a 'lower' state
- a property "Type" that could change in real-time would have to implement every aspect Assign does, but  "flatening" the inheritance. Besides, it would assume that going from type1 to type2 and from type2 to type1 again is of little consequence. It might not be what is needed, and 2 classes (or more) can emphasize those (needed) aspects, and ease implementation
- the overhead of copying a few fields is not an argument, as it is not likely to happen often.

If it's done right, this kind of "upgrade"  of objects can be very convenient and efficient

forgot the Create :

constructor TSecond.Create(tf:TFirst); // Will essentially call Assign

I forgot the main black point of this : You can't have many references to the object, otherwise it's going to be a nightmare to update all new pointers to the new upgraded object.

But that is not much of a problem because
a) it's always a bad idea to have multiple references to the same object, except for localized methods during a process, which is unavoidable.
b) the objects that needs this kind of subterfuge most certainly needs already to be gathered in a collection of some sort (TObjectList), and they are always accessed through this list. So there is just one place to update, and this can be done in single Constructor/Destructor :

Constructor TSecond.UpgradeFrom(tf:TFirst);
begin
 Assign(tf);
 MyObjectList.Insert(MyObjectList.Remove(tf),Self);
 // Automatically free tf (with MyObjectList.OwnsObject:=True) 
 // and insert the new object in its exact position
end;

                                              

1:
2:
3:
4:
5:
6:
7:

Hi! Thanks for you relply.
What's happen if I do:

Var obj1 : TMyObj1;
Var ObjBase : TBase;

Type
TMyObj1 = class (TBase)
.....
end;

ObjBase := TBase.Create;

later on in the code:

Obj1 := TMyObj1(ObjBase); ????


 

until you don't call any specific methods of TMyObj1, this will not complain.
a cast does not transform your object, it just allow (trying) access your object as another. You have to be very sure that everything you do after with this casted object is allowed by the base object.
So, you will have no gain, and you risk having loads of trouble by confusing yourself.

say for clarity, you have a property in TMyObj1 that is not there in TMyBase :

TMyObj1 = class (TBase)
private
  _Prop:Integer;
public
 property Prop:integer read _Prop write _Prop;
end;

if in your code you do
Obj1 := TMyObj1(ObjBase); ?
Obj1.Prop:=10;

this will compile, but on the property setting you will have an access violation error : you try to read a memory zone that is outside the memory block pointed by your ObjBase object

I guess you are trying to build an electronic scheme editor, so you will have to handle a bunch of basic components, that can have a different number of pins or specific properties. So You might want to manage what kind of transformation is possible, and what properties can be salvaged from the older component to the new one.
Creating a supercomponent with all possible properties is probably the best way to throw yourself through the window in a few month, as you will maybe have to implement some "virtual testing" of these scheme, or some other complex operations. You have to have different classes, and you have also the need for ugrade, so....

no, really, what you have to do is implementing an UpgradeFrom virtual method in your base class, to manage all common fields and when needed override and/or overload it to manage different pairs of transformation (from TypeA to TypeB)

...robably the best way to throw yourself through the window in a few month

not good. :-)

no, really, what you have to do is implementing an UpgradeFrom virtual method in your base class, to manage all common fields and when needed override and/or overload it to manage different pairs of transformation (from TypeA to TypeB)

An object of typeB may have a method i.e. DoSomeTask (implemented using interface) which is not part of TypeA definition. The DSomeTask procedure collect some date and do some calculation as well in order to valorize the propreties of TypeB object. So, the user may want to create for instance a node of typeA and then later on turn it into TypeB without loosing previous values (the ones of the baseclass). So I will be glad if you may guide me step by step on how to implement this virtual method. I caught what you have suggested at 60% :-)) some code may be helpful.
thx

Well done.