[lazarus] About compatibility???

Fri Mar 8 02:21:50 EST 2002

Matjaz Mihelic wrote:

> Mattias Gaertner wrote:
>
>>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 to
>>>>maintain (used C, FPC, XML...), but I wonder how others think about that
>>>>kind 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 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.
>>>
>>
>>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
>
I think this might be interesting, if the level of abstraction is done 
right (input and output to a control). If then extended to sort of  some 
internal transaction system, this could even replace TAction stuff (maybe).
For a start, could you make a sample implementation on a copy of TEdit 
into a separate tree so that we make try it out and evaluate? I'd like 
to see how it works out implemented, as theory always looks bright :-)

There is always a place for better approaches !

(And Delphi compatibility can be resolved later just by means of some 
kind of preprocessor, or one time import processor. There just have to 
be a good reason).

Note that this is only my opinion, and speaking for myself only.

Michal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00006.bin
Type: application/octet-stream
Size: 3253 bytes
Desc: "S/MIME Cryptographic Signature"
Url : http://localhost/pipermail/lazarus/attachments/20020308/c4445046/bin00006.bin