[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