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

[Richard Dale]

On Friday, June 25, 2010 07:17:34 am Chris Burel wrote:
> 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.
In QtRuby I don't subclass the Ruby Array class, I just make the Qt::Polygon 
interable:

	class Polygon < Qt::Base
		include Enumerable

		def each
			for i in 0...count
				yield point(i)
			end
			return self
		end
	end

However, when I tried the above code, it didn't work because 
Qt::Polygon.count() wasn't defined. So I must fix that.

Still in general I still think it would be nice if smokegen could handle 
templated classes at some point. We can still choose to ignore them for 
specific languages like C#.

-- Richard