[fpc-pascal] Re: fpc-pascal Digest, Vol 19, Issue 24

[Mattias Gaertner]

On Thu, 16 Mar 2006 08:24:12 -0800 (PST)

> Message: 7
> Date: Thu, 16 Mar 2006 01:13:57 +0100
> From: Mattias Gaertner <nc-gaertnma at netcologne.de>
> Subject: Re: [fpc-pascal] Re: OpenDelphi.org
> To: FPC-Pascal users discussions
> <fpc-pascal at lists.freepascal.org>
> Message-ID:
> <20060316011357.755c4dab at limapholos.matom.wg>
> Content-Type: text/plain; charset=US-ASCII
> 
> On Wed, 15 Mar 2006 15:57:23 -0800 (PST)
> 
> > 
> > 
> > --- fpc-pascal-request at lists.freepascal.org wrote:
> > 
> 
> <snip>
> 
> > 
> > FPC is Ok but a few years ago I examined Lazarus
> > codebase and I saw Lazarus is hacking Class parents
> > on-the-fly for its normal operations so I
> immediately
> > lost my interest. 
> > Is this changed recently?
> 
> If you mean creating the VMT at runtime, then the
> answer is: yes, it 
> still
> does.
> What are the alternatives?
> 
> Mattias
> 
> Yep I meant creating VMT at runtime,It does not seems
> like a good practice to me. 
> 
> Delphi's streaming system wont work without RTTI, and 
> Delphi's RTTI is only for streaming. RTTI and message/
> dynamic methods is embedded in compiler to support VCL
> and IDE. So writing a Delphi-like IDE without support
> of FPC team / compiler could be hard work but I still
> wont think 
> creating VMT in runtime is way to go. Cross-platform
> issues and these kind of hacks/ shortcuts  is
> overcomplicating things in Lazarus codebase, I think.

Overcomplicating is the wrong word, as this 'hack' was used to avoid
complication.
By creating a vmt, the rest of the code and any component work without
modifications.
The alternative is to create a normal TForm/TDataModule and fake/extend all
places, where the fake vmt is used. That are all places where RTTI or the
Classname are used. And of course some 'is' and 'as' operators.
The vmt itself are a few pretty simple records and they are cross platform.
The real hack is the method pointers. They will eventually replaced by
fakes.

 
> Alternative? 
> I prefer a solution based on non ref-counted
> interfaces  for example (although this may need some
> support from compiler side e.g UID's for non
> ref-counted interfaces/ interface delegation or
> something, and means nearly rewrite, so I dont think
> this will happen)

Can you give an example, how this should work?


> User-level delphi compatibility is enough for masses
> (e.g Form designer, properties vs), as long as it have
> quality/stability,  internal workings of components is
> not so important, but as I said above, with current
> implementation I dont think Lazarus is
> production-ready or it will become.


Mattias