[lazarus] compile error on New Sources from cvs - FIXED
Mattias Gaertner
nc-gaertnma at netcologne.de
Fri Nov 28 04:45:12 EST 2003
On Fri, 28 Nov 2003 08:53:32 +0100 Micha Nelissen
<M.Nelissen at student.tue.nl> wrote:
> Marc Weustink wrote:
>
> > At 23:24 27-11-2003, Mattias Gaertner wrote:
> >
> >> On Thu, 27 Nov 2003 23:10:24 +0100 Marc Weustink
> ><marc at dommelstein.net>> wrote:
> >
> >
> > [snip]
> >
> >> > I don't think this is the way to go. Now, if the interface gets
> >> extended
> >> > with mode direct calls, we can add a TBase... for every
> >> > TComponent/TControl etc we need.
> >> >
> >> > OK, what happened.
> >> >
> >> > The LCL needs the baseinterface..
> >> > The baseinterface needs the LCL..
> >> >
> >> > That means problems. Sure you can introduce all kinds of base
> >> classes, but
> >> >
> >> > how would you do this with a TBaseControl and a TBaseWinControl ?
> >> > If we are going to introduce dedicated interface classes, it starts
> >to> > look like a discussion we had a few years ago.
> >> >
> >> > Seen the latest problems and implications, I wonder if we should
> >> continue
> >> > the last changes we made. IMO, we should undo it and try another
> >route.>
> >> What about replacing TBaseMenuItem with TComponent?
> >
> >
> > Hmm...
> >
> > That would require a lot of typecasting, but is better.
> > The new situation would be
> >
> > The LCL needs the baseInterface and FCL
> > The baseInterface needs FCL
> > The XXXInterface needs LCL and baseInterface and FCL
> >
> > I don't see a problem here.
>
> I think the problem is that we are acting as if the LCL and the
> interface are seperate entities. As if they are independent. We say: the
> LCL uses the interface as if the interface is a layer completely below
> the LCL. But it is not. Mattias already said this of course, but it took
> a while for me to see the 'whole picture'. Correct ways to fix it:
> 1) Make the interface really indepedent. This means you should be able
> to rewrite all the programs in examples/ without using the lcl at all,
> only interfacebase.
Speaking of interfacebase: Yes, you can do that.
But who wants to?
> 2) Regard the lcl and interface as one layer. Then placing the interface
> on top of the lcl will justify not being able to write those examples
> without the lcl, because the interface depends on it, which it does.
Maybe this can enlighten this discussion:
- There are 4 players: LCL base, interface base, LCL and the various
interfaces
- Goals:
+ LCL base, interface base and LCL are platform independent
+ Interfaces are platform dependent
+ compile once the platform independent part,
then compile every platform dependent part separately
(e.g. under linux: compile LCL once, then gtk, gnome, gtk intf)
=> interfaces depend on interfacebase
=> this point does not imply any relationship between LCL
and an interface
+ LCL uses the interface base to talk to the real interface
=> interface base on same or below lvl than LCL
=> still no implication for the interfaces
+ LCL contains the logic, interface base not
=> LCL and interface base are not on same lvl
+ the LCL base are just some very basic functions
and types, which can also be moved to the FCL,
but are not. They are below all.
Ergo:
- LCL is above interface base is above LCL base
- Still no implication for the relationship of the LCL and the interfaces.
Not even the implication that we have to separate them. So, the gtk intf was
implemented depending on the LCL to make programming easier. This was just a
decision for the gtk intf. Other interfaces don't need to depend on the LCL.
For example: Someone can write a MyCL using the interfacebase and write an
interface for say wxWindows.
But: No one wants to use the interface base without the LCL. The interface
base is not very comfortable.
> Mattias: "So, I think, eventually we need to get rid of the generics."
> I agree, and I have some ideas but I am unsure how to do it exactly.
Then we are two. I know, how to fix the smart linking (getting rid of the
case statements and such things), but I fear the consequences.
Mattias
More information about the Lazarus
mailing list