[fpc-devel] Propose: change TComponent.Tag from longint to PtrInt

[Daniël Mantione]

Op Mon, 4 Sep 2006, schreef peter green:

> 
> >
> > > Me2.
> > >
> > > Just one disadvantage:
> > > The Tag is published.
> > > If someone stores a 64bit value and the component is stored,
> > > the stream can not be read under 32bit anymore.
> >
> > ...which makes it impossible to use streams for anything derived from
> > Tcomponent, which is really a lot. I don't think we should break this
> > feature to allow broken code to work.
> ahh the joys of conflicting requirements,
> 
> I don't consider storing a pointer in the tag is broken code, it was
> considered the accepted way to maintain a pointer to your custom data from a
> standard control and there is often no simple alternative.

In 16 bit days it was considered acceptable to typecast pointers into 
records and just increase their offset. However, it was not portable. 
Making your code portable requires some effort. This kind of code is just 
one example of things you should not do in portable code. If Borland had
intended this as a pointer , they would have declared it as a pointer.

Of course there is a simple solution, derive a class and add fields to 
taste.

> how does streaming of components work? would it be possible to make tag able
> to accomodate a pointer while only writing the least significant 32 bits to
> a stream?

Yes, this could be an acceptable solution, since you can never stream 
pointers anyway.

However, I am still worried about a slippery slope. There exists many data 
types with longints in them and we simply cannot declare them all longint 
just because someone might store a pointer in it.

Daniël