[[lazarus] Design issues]

[Michal Bukovjan]

Florian Klaempfl <Florian.Klaempfl at gmx.de> wrote:
> 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  

Yes, I am thinking about this same thing. The virtual method concept would be
much more clear, maybe some abstract interface object and then for each widget
there could be a mapping extended interface object descendant.
BTW, I wonder even Borland uses CM_??? concept which seems to me redundant on
many places. Does anybody know why use these internal CM_ messages at all?

I, too, don't like huge case statements, it just doesn't feel good :-)

> - 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

That would end up being the same - creating new functions for new widgets.

> 
> 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.

Hmm, definitely worth considering.

Michal Bukovjan

____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.