On Mon, Apr 12, 2010 at 2:56 PM, Viktor Szakáts <harbour...@syenar.hu> wrote:
> Hi,
>
>> Hi Viktor, I was about to send this message to the list when I had a
>> shocking vision....
>>
>> In postgres.c it is NORMAL to discriminate between objects... there is
>> no use in passing type X instead of type Y and it must be avoided and
>> RTE is good.....
>>
>> But in Qt we have a HIERARCHY !
>>
>> It is perfectly normal to pass a QPushButton to a function that
>> expects a QObject !!!!!!!!!! since QObject is a super-class !
>>
>> Since we don't store the object hierarchy Pritpal just checks that
>> ClassName() starts with a Q or HB .... and keeps the finger crossed...
>
> That's even worse than handling everything as the base class.
It's not a different situation from c++...
> First I think we need to make sure we can identify the
> class of every GC allocated objects.
If you do this, you need to implement and mantain a class hierarchy in
the code, checking ancestors for every access. And since every Gui
object . Probably as first step we may differentiate between
"base-classes": this will avoid some class of problems....
Also, we must keep in mind how some methods are redefined....
Example from QRadioButton....
14 protected functions inherited from QAbstractButton
37 protected functions inherited from QWidget
7 protected functions inherited from QObject
1 protected function inherited from QPaintDevice
If I call qRB:height() actually is called a QWidget:height() that is:
RETURN Qt_QWidget_height( ::pPtr ) that is: hb_retni(
hbqt_par_QWidget( 1 )->height() );
and hbqt_par_QWidget( 1 ) becomes, in a "strict" type checking as
per my (unpublished) proposal: hbqt_par_QWidget( 1,
&pointer_to_qwidget_destructor )... since ::pPtr was created by
QRadioButton, hbqt_par_QWidget will return NULL....
In hbqt_par_QWidget( 1, &pointer_to_qwidget_destructor ) we may
implement hierarcht knowledge, or via an iterator (going up the
hierarchy until no more items or an item is found) or via a hasehd
table...
> If we can do this,
> we may make the next step and properly filter accepted
> parameters.
Yes, it may be a next step.
> For this we also need to maintain the layout
> of the QT class hierarchy. This raises other issues, like
> how to keep this in sync with QT version. This information
> BTW is already maintained in HBQT on the .prg level.
Yes, it is, not completely but it is. (BTW: muliptle inheritance is
possible in harbour ?)
> Another random thought: Maybe it would be worth to
> investigate if it would be useful to merge current
> separate .prg level HBQT class wrappers with low-level
> method implementations on the .cpp level.
low-level method implementations can be merged, and it would be good
to make them static (calling them directly is a way to problems). But
some hbqt_gcAllocate_Q* functions are called from other objects and so
they can't be hidden...
> In Harbour it's possible to create classes purely in .c/.cpp
> code, so this may give performance and may help maintaining
> the whole thing. (see src/rtl/errapi.c)
I saw a library where c code was included in a prg file by a #pragma...
> BTW, if we could properly identify object types, current
> hack of method overloading on the wrapper level could also be
> change for a better solution.
There are easy and not easy solutions, at both c++ and prg code
level.... In some objects there is already a form of constructor
overriding, as in QRadioButton,
in other similar cases there is no overriding (QPushButton has 3
constructor)....
if( HB_ISCHAR( 1 ) )
pObj = ( QRadioButton* ) new QRadioButton( hbqt_par_QString( 1
), hbqt_par_QWidget( 2 ) ) ;
else
pObj = ( QRadioButton* ) new QRadioButton( hbqt_par_QWidget( 1 ) ) ;
> I mean code like this:
> ---
> HB_FUNC( QT_QTRANSLATOR_TRANSLATE )
> {
> hb_retc( hbqt_par_QTranslator( 1 )->translate( hbqt_par_char( 2 ),
> hbqt_par_char( 3 ), hbqt_par_char( 4 ) ).toAscii().data() );
> }
>
> HB_FUNC( QT_QTRANSLATOR_TRANSLATE_1 )
> {
> hb_retc( hbqt_par_QTranslator( 1 )->translate( hbqt_par_char( 2 ),
> hbqt_par_char( 3 ), hbqt_par_char( 4 ), hb_parni( 5 ) ).toAscii().data() );
> }
transalte declaration is different in Qt 4.6... but maybe it was just
an example...
> ---
> (though in this specific case it could be fixed easily even now)
Yes.
Francesco
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
