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.
> I believe it is the same at C++ level... At Harbour level we may check
> if the object has a specific class member before accepting.... At GC
> level we may differentiate destructors according to the main class:
> objects deriving from QObject have destructor D1 and use guarded
> pointers...other super-classes have other destructor so that we can
> avoid some stupid parameter mistakes.... This permits to pass a
> QPushButton where a QObject is expected and it will work.... but it
> will also permit to pass a QObject to a function expecting a
> QPushButton and this will GPF at 99%....
>
> What do you think about it ?
First I think we need to make sure we can identify the
class of every GC allocated objects. If we can do this,
we may make the next step and properly filter accepted
parameters. 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.
So you could make sth like:
HB_FUNC( QT_SOME_METHOD )
{
if( hbqt_par_isQPUSHBUTTON( 1 ) )
... pass the call to QT...
}
or
HB_FUNC( QT_SOME_METHOD_2 )
{
if( hbqt_par_isQCONTROL_or_descendant( 1 ) )
... pass the call to QT...
}
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.
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)
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. 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() );
}
---
(though in this specific case it could be fixed easily even now)
Just thoughts.
I'm also forwarding this to mailing list in the hope to
ignite interest in other contributors.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
