[lazarus] Design issues

Florian Klaempfl Florian.Klaempfl at gmx.de
Mon Feb 21 17:35:49 EST 2000


Hi,

I'am still curious about some design decisions of lazarus:

- Why do you still use the strange message concept to communicate with the
  toolkit interface??? Virtual methods or another class ttoolkitinterface
  could easily do the trick. I know messages are a clean OOP concept 
  but in compiled languges they are replaced by virtual calls or methodpointers  
- Also the tgtkcomponent.createcomponent seems to be a rather strange idea to me! 
  As far as I can see you have always to modify the lazarus sources if you're creating
  a new type of component? If you want to be toolkit independend you could
  create functions like 
  CreateButton, CreateToolbar etc.
  The same applies to tgtkobject.setproperties

Both things have some impact on performance: FPC and the processor tries to do
good branch prediction :), but you puzzle them by using a lot of case statements,
let it me point out more precisily:

Example TProgressBar.SetPosition:

It calls ApplyChanges, well quite ok, but we wouldn't need to change all properties,
but now SendMessage is called and here you loose two pieces of information in the data
flow:
the object type and what you want to do: SendMessage figures out again what you want
to do by testing a lot of cases and setproperties figures out again of what class
type the sender was! I think the processor has to do better things! 

Clean proposal for a solution:

twincontrol or tcontrol gets a pointer to a class ttoolkitinterface (similiar
to the handle under windows) and ttoolkitinterface has 
childs like ttoolkitbutton with a appropritate methods.






More information about the Lazarus mailing list