[fpc-devel] Language extension: absolute for classes

[Michael Van Canneyt]

On Sun, 1 Oct 2006, Daniël Mantione wrote:

> 
> 
> Op Sun, 1 Oct 2006, schreef Michael Van Canneyt:
> 
> > 
> > 
> > On Sun, 1 Oct 2006, Micha Nelissen wrote:
> > 
> > > Michalis Kamburelis wrote:
> > > > All you want is just to cover in class B identifier "Field" of class A.
> > > > So you should make "Field" a dummy function in class A (that just
> > > > returns a field value), and then you can redefine function name in
> > > > descendant classes. See the example below. Within the scope of class B
> > > > the "Field" function will return class G.
> > > 
> > > This is a smart hack, at best. It's abuse of function syntax IMHO (as if
> > > they were fields). Second, you cannot assign to a function.
> > > 
> > > If the functions were inline, it could be as optimal, I agree; then you
> > > have essentially localized the typecast to one place.
> > > 
> > > I just want to tell the compiler what I can guarantee, but what it
> > > cannot automatically infer.
> > > 
> > > Thank you for the suggestion,
> > 
> > I don't think your solution is any cleaner than what he suggests.
> > It's also a 'smart hack', after all. Just like in the old DOS days,
> > when one would declare an array of bytes with 'absolute' at the 
> > location of the VGA or Hercules text screen card...
> > 
> > Just an opinion, of course...
> 
> Well... You can do absolute in procedures:
> 
> var b:byte;
>     c:char absolute b; 
> 
> Now, you can consider this bad programming, but it is just a lowlevel 
> trick. It is the addition of low level functions that was the key in 
> making Pascal suitable for real world use.
> 
> Now, if absolute is allowed in procedures, is there a good reason to 
> forbid it in classes? I.e. what is fundamentally bad about...
> 
> type   t=class
>          b:byte;
>          c:char absolute b;
>        end;
> 
> ?
> 
> The use of specialization is interresting:
> 
> type   t=class
>          a:Tabractclass;
>          b:Tspecialized_class absolute a;
>        end;
> 
> Using b, instead of a, provides in certain operations like calling 
> inherited methods, provides extra information to the compiler. It'll be 
> interresting to think wether it is theoretically possible to do extra 
> optimizations using this information.

For clarity:
I am not opposing it, but I do consider it a dirty trick in both cases...

Michael.