[fpc-pascal]Problem with TReader and integer idents

[Michael Van Canneyt]

On Tue, 6 Aug 2002, Mattias Gaertner wrote:

> On Tue, 6 Aug 2002 13:45:00 +0200 (W. Europe Daylight Time)
> Michael Van Canneyt <michael.vancanneyt at wisa.be> wrote:
>
> >
> >
> > On Tue, 6 Aug 2002, Mattias Gaertner wrote:
> >
> > > Hi all,
> > >
> > > I have an object stream for a component with a published property Color: TColor. The stream contains the statement:
> > > Color = clRed
> > > Since 'clRed' is an identifier, TReader lookups for an IdentToInt function via FindIdentToInt declared in classes.pp. FindIdentToInt needs a pointer to a TTypeInfo.
> > >
> > > The problem is that the TypeInfo pointer differs from unit to unit.
> > > A TypeInfo(longint) in classes.pp is not the same as a TypeInfo(longint) in the program.
> > > This is incompatible to Delphi.
> > > So, the program can't register a valid TypeInfo pointer.
> > >
> > >
> > > I guess, it's not easy to fix this, so I suggest a workaround:
> > >
> > > The function FindIdentToInt can be extended to not only check for TypeInfo pointers, but also for the values in the typeinfo:
> > >
> > > function FindIdentToInt(AIntegerType: Pointer): TIdentToInt;
> > > var
> > >   i: Integer;
> > > begin
> > >   with IntConstList.LockList do
> > >   try
> > >     for i := 0 to Count - 1 do
> > >       with TIntConst(Items[I]) do begin
> > >         if (IntegerType = AIntegerType)
> > >         // start of workaround --------------------
> > >         or ((PTypeInfo(AIntegerType)^.Name = PTypeInfo(IntegerType)^.Name)
> > >           and (PTypeInfo(AIntegerType)^.Kind = PTypeInfo(IntegerType)^.Kind))
> > >         // end of workaround --------------------
> > >         then
> > >           exit(IdentToIntFn);
> > >       end;
> > >     Result := nil;
> > >   finally
> > >     IntConstList.UnlockList;
> > >   end;
> > > end;
> >
> > Will this not lead to problems with enumerated values ?
> >
> > You can perfectly have the same enumerated name in 2 units for 2
> > different enumeration types.
> >
> > Unita.EnumA = (enOne,onTwo,EnThree);
> > Unitb.EnumB = (enZero,enOne,enTWo);
>
> Here the property types can be EnumA and EnumB, so I think this should work.
> But of course you're right, the name and kind is not sufficient to distinguish types.
> OTOH FindIdentToInt is currently rather useless. So, I guess no one uses it. With the workaround it works pretty well in the intended way.
>
>
> > So I think a compiler solution is in order, here. Florian, any ideas how
> > this should be solved ? Maybe typeinfo should always be included in the
> > unit where something is defined ?
>
> Sounds good.
>
>
> > OTOH, longint is a special case, it is an internal compiler type...
>
> Ok, maybe typeinfo(longint) was a bad example. I don't want to register longint.

Why else do you need it if not for integer types ?
It's not needed for enumeration types, since there you can use getenumname.
In all other cases, the implementation should work as it is, no ?

Michael.