[lazarus] About compatibility???

[Michael.VanCanneyt at Wisa.be]

On Fri, 8 Mar 2002, Matjaz Mihelic wrote:

> I'm developing a new approach that I need for software I'm developing (a
> bit more usefull than Borland has developed) and I'm interested how
> important is direct Delphi compatibility to lazarus project, since I
> would like to discuss possibility of change in CVS (extending some things).
>
> REASON:
> Here is the reason why: I need few different approaches to data with
> same form in my app and I wouldn't like to develop new edit control for
> every one. I've always hated to have twenty edit controls just for
> accesing different data) So I'm developing a kind of data wrappers that
> use standard component set that's already in lazarus.
>
> EXPLANATION:
> I would like to contribute them to main branch, but only if you'd be
> comfortable with breaking delphi and kylix component compatibility (not
> by losing but gaining).
>
> Idea means avoiding developing dbcontrols and make editing wrappers,
> which can be connected to any source not only db. So far there are only
> lightly changed lcl components that don't make control incomaptible with
> the one in CVS. Light change means few lines of code for one control and
> a bit more for TControl but still not much. Same control can be
> standalone or wrapped one. Question is not which control would we use,
> question is which wrapper or listwrapper (DB, XML,
> whateveryounameit...). Same function that would allow app to combine
> several complitely different approaches in same app, with no form
> difference, except data wrappers. (P.S. It would not disable possibility
> to make delphi compatibility layer based on wrappers, with a little
> clean code, this controls could easily be developed, but I personally am
> the last person that would be interested in that)

There is no reason why this could not be developed parallel to the
development of 'traditional' DB controls in lazarus. There are several
approaches possible to this problem. Yours can be one of them.

But you should explain your ideas in more detail so the impact of the
changes can be estimated.

>
> It's not quite developed yet (first results are showing already), but in
> a month or so, there should be some first final results already.
>
> I know this is a bit selfish since I've got no Delphi and Kylix appz to
> maintain (used C, FPC, XML...), but I wonder how others think about that
> kind of approach.

I think everyone has an open mind :-)

>
> The second question one is more lazarus IDE connected: Does anybody
> except me misses some kind of preprocessor in pascal. If borland hasn't
> included one that should not be the rule for pascal not allowing that
> option.

I don't think we will add a preprocessor to the compiler; macroitis is a
serious disease of C and should be kept as far from the language as
possible, however I see no reason why an editor could not pipe each file
through a preprocessor before feeding it to the compiler. What is more, in
an IDE, the preprocessor could be specified - making it a more powerful tool
than integrating the preprocessor in the compiler. On top, it should not
be hard to add.

Michael.