[lazarus] About compatibility???

[Matjaz Mihelic]

Mattias Gaertner wrote:
20020307235955.70e5b17e.nc-gaertnma at netcologne.de">
  On Thu, 7 Mar 2002 22:16:38 +0100 (CET)<Michael.VanCanneyt at wisa.be> wrote:
  
    On Fri, 8 Mar 2002, Matjaz Mihelic wrote:
    
      I know this is a bit selfish since I've got no Delphi and Kylix appz tomaintain (used C, FPC, XML...), but I wonder how others think about thatkind of approach.
      
      
      I want Delphi compatibility to easily upgrade Delphi code to FPC not to create hybrids.Can u give a more detailed example of your aproach?
      
        
          The second question one is more lazarus IDE connected: Does anybodyexcept me misses some kind of preprocessor in pascal. If borland hasn'tincluded one that should not be the rule for pascal not allowing thatoption.
          
          I don't think we will add a preprocessor to the compiler; macroitis is aserious disease of C and should be kept as far from the language aspossible, however I see no reason why an editor could not pipe each filethrough a preprocessor before feeding it to the compiler. What is more, inan IDE, the preprocessor could be specified - making it a more powerful toolthan integrating the preprocessor in the compiler. On top, it should notbe hard to add.
          
          I totally agree, that Preprocessing is a serious disease of C and should be kept as far as possible. There are far more drawbacks than goodies.But preprocessing in the normal sense is also pain for an IDE with code completion features. Delphis code insight is neither able to work with include files, nor compiler directives. The codetools already support include files and there is slight support for "dead" code, left out by compiler directives. But they have to do a lot of bookkeeping. FPC Macros will eventually be supported, you can think of them as small include files. Now think about automatically adding code, deleting code, replacing code and moving code. Code completion features works on the preprocessed code but it alters the sources itself. So it has to consider both sides of the metal at once. Macros will add a layer between it.And do not just think about the code insight features. The codetools will become much better. ;)<
br>But I'm sure, we can add functions to the IDE to get some "preprocessing" features without the big drawbacks. Best of both worlds.Mattias_________________________________________________________________     To unsubscribe: mail lazarus-request at miraclec.com with                "unsubscribe" as the Subject    archives at http://www.miraclec.com/list_archives/lazarus
          
Basic idea is not to take away anything but to add a EditWrapper component,
in some points of class function there would need some
          
  if Wrapper <> nil then
    
 
  else 
    DoClassicStuff;
          
Where it would be needed
  Wherever state and editing comes in question, by starting and stoping editing
          
Basically, idea goes like this
instead of TDataLink for TDBEdit
Add a wrapper to TControl, TEdit has inherited that and our new TEdit can
be controled from anywhere or any data structure same as TLabel, TListbox....
>>>> Our wrapper would mean same control over value and state
of any kind of control.
          
Use this wrapper as is, and simulate TDataLink to get compatibility >>
TDBEdit
          
This way using my suggestion there would be a wrapped control over editing,
but easy gaining compatibility with Borland.
          
Again, nothing, no any function would be taken out. There would be only addition
over state and value from outside for all components accesing the standard
wrappers.
          
TWrapper = class(TObject)
  Control: TControl;
  OwnerList: TWrapperList;
  State: TState;
  Value: TVariant; // or anything
end;
          
TWraperList = class(TList)
// I think it's obvious where I'm pointing
end;
          
This way would allow us to reverse control over data controls. Have one derived
special wrapper list for every job for any component, and not a complete
control set for every kind of data. You change wrapper, you changed data
source for complete form.
          
 Hasn't nobody else but me being bored using one control set for accesing
normal input, one control set for DB, one control set to control for accesing
Btrieve....???? I already tried to do something like that on Delphi, but
the damn f...up was closed for any kind of internal lower editing of components.
I would just end up deriving another set of components??? Bugger... Every
time I set up Delphi for me I end up with hundred of components, but there's
only 20 or 30 basic ones by using my solution. And there's always simple
way to make compatibility set that would allow to set propertys other way
(Since component is already working with wrapper and propertys are compatible,
maybe I'm confuzed but doesn't that mean we'd gain compatibility???).
          
In case of preprocessor, I was asking about. Wouldn't be nicer to write a
preprocessor that knows how to <#include somelibrary.h>, than waiting
some of us to translate C headers in pascal (that's first idea that comes
to my mind, and this one would put project much further than it really is,
there would be no need to develop or translate things already done, but case
of preprocessing I'm thinking one is simply as suggested >> IDE specified
preprocessor tool, started in another CVS project completely out of, or with
lazarus but different branch (This way lazarus wouldn't suffer any consequences,
but gain a lot))?
          
matjaz