[Kde-bindings] Support specific instantiations of template classes in Smoke

[Chris Burel]

2010/6/24 Arno Rehn <arno at arnorehn.de>:
> On Thursday 24 June 2010 02:34:14 Chris Burel wrote:
>> Richard and I were discussing this today, that it'd be great if Smoke
>> could wrap instantiations of template classes.  It came up because
>> QPolygon inherits from QVector<QPoint>, but because QVector<QPoint>'s
>> methods are not available in Smoke, a significant portion of the
>> QPolygon API is unavailable to language bindings.  I tried placing
>> "QVector<QPoint>" (the XML-encoded version of QVector<QPoint>)
>> in the classes section of smokeconfig.xml for qtcore smoke, but the
>> resulting smokedata.cpp only had an entry in the inheritanceList for
>> "QVector", and no entry in the classList.  It'd be really great to get
>> that to work.
> I don't know if this is really the right approach. At least in languages where
> it is possible I would implement QPolygon as a subclass of the language-
> specific 'List' class. If you map QVector to the native List class in the
> bindings, then it would feel strange to suddenly have to deal with the
> original QVector API on QPolygon.
>
> In C# I did this for the KUrl::List class. In c++, it inherits from
> QList<KUrl>, and in C# we inherit from System.Collections.Generic.List<KUrl>.
> The additional methods are then implemented in native C# or with native C
> calls and some manual marshalling.
>
> It's definitely more work to implement, but results in a much nicer API, in my
> opionon.
>
> --
> Arno Rehn
> arno at arnorehn.de
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>

That does sound cool, but unfortunately some languages' native arrays
are not objects.  (Obviously I'm biased, since my target is Perl).  In
Perl, all objects are just a reference to a scalar, array, or hash,
with some information telling it where to look for subroutine calls.
For PerlQt, all the objects are hashes.  This is convenient, because
if you want to add a "property" to your object, you just assign to a
hash key.  I could make QPolygon return an array reference instead of
a hash reference, and with Perl's tie() mechanism get a syntax that
feels like a native Perl array.  But then subclassing those wouldn't
work too well, because you'd have no place to add Perl properties to
your objects, since you can't add hash keys.  But I'm not even sure
why you'd want to subclass QPolygon to begin with.

Also, there are 4 classes that subclass from QVector, QPolygon,
QPolygonF, QStack, and QXmlStreamAttributes.  So I'd have to write the
same code 4 times.