On 2012-05-13 13:38:36 +0200, Sven Barth wrote: > On 13.05.2012 12:46, Leonardo M. Ramé wrote: > >On 2012-05-13 10:53:42 +0200, Sven Barth wrote: > >>On 13.05.2012 02:49, Leonardo M. Ramé wrote: > >>>On 2012-05-12 13:07:18 -0300, Leonardo M. Ramé wrote: > >>>>Thanks Sven and Michalis. Using the suggestion by Michalis, I got a > >>>>solution mixing Generics and regular objects. > >>>> > >>>>What I'm pursuing is to replace my TCollection based ORM, with a > >>>>Generics based one, this allow users to write less code, in a clearer > >>>>way. > >>>> > >>>>The way the ORM works, is to create a TCollection instance, then execute > >>>>an ORM's method to load/save data into/from it, example: > >>>> > >>>>var > >>>> lCustomers: TCustomers; // this is a TCollection descendant > >>>>begin > >>>> lCustomers := TCustomers.Create; > >>>> FConnector.LoadData(lCustomers, []); > >>>> ... do something with lCustomers ... > >>>> lCustomers.Free; > >>>>end; > >>>> > >>>>As you can see, FConnector.LoadData receives a TCollection as parameter, > >>>>and using RTTI, it fills each TCustomer published property. > >>>> > >>>>With Michalis's solution, I can turn my ORM from TCollections to > >>>>Generics with very little changes, see how small is the unit customer > >>>>now, instead of a complete TCollection/TCollectionItem definition: > >>>> > >>> > >>>Following the same subject, inside a method receiving an TFPSList, how > >>>can I know the type of items it will contain, even if the list is > >>>empty?. > >>> > >>>In a TCollection, I can use myCollection.ItemClass to know it, but in a > >>>specialized Generic type, how can I know, in an abstract way the type of > >>>a TFPGList<T>?. I mean, what type is T?. > >> > >>You can't. That's why the method with the "parent class" might be considered > >>less powerful than the one with generic methods/procedures. > >> > >>Regards, > >>Sven > >> > > > >Hm. Another thing I'm stuck on, is specialized classes doesn't seem to > >have a ClassName, am I righ?. > > > > Specialized classes are just normal classes. They DO have a class name, but > it is not the one that you might expect. > > Following example: > > === example begin === > > type > TTest<T> = class > > end; > > TTest1 = specialize TTest<LongInt>; > TTest2 = specialize TTest<LongInt>; > > begin > with TTest1.Create do > try > Writeln(ClassName); > finally > Free; > end; > with TTest2.Create do > try > Writeln(ClassName); > finally > Free; > end; > end. > > === example end === > > In both cases the same name "TTest$1$crc31B95292" will be written which is > composed out of the name of the generic (which is "TTest$1", where the "$1" > stands for "has one generic parameter") and the crc of the given type > parameters. This name is an implementation detail though, so DO NOT RELY ON > IT, because I WILL change it sooner or later (to be more like > "TTest<System.LongInt>"). > > The fact that the name is in both cases the same is because the generic is > only specialized once per unit, so that code like the following can find the > correct specialization (this works in mode Delphi): > > === example begin === > > var > t: TTest<LongInt>; > begin > t := TTest<LongInt>.Create; > try > t.Value := TTest<LongInt>.SomeConstant; > finally > t.Free; > end; > end. > > === example end === > > Regards, > Sven >
Ok, so, what happens if I declare the same specialization in different units, then pass instances of each specialization to the same method, its ClassName should be the same, no?. for example: ---- unit1; ... type TCustomers = specialize TFPGList<TCustomer>; ----- ---- unit2; ... type TCustomers_from_branch1 = specialize TFPGList<TCustomer>; ----- What I would like, is, when I ask for the instance's classname, it write TCustomers and TCustomers_from_branch1, instead of TFPGList$1$.... Is this planned?. -- Leonardo M. Ramé http://leonardorame.blogspot.com -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
