[RQt-devel] recent smoke update

[Michael Lawrence]

I'm now thinking we're better off drinking the kool-aid and moving to S4 for
representing these objects. At least the complex ones that would need to
become a list. Validation would be much easier. And it would be
self-documenting, to an extent.

If we did that though, we'd want to be pretty consistent, so even QMatrix
would become an S4 class that I guess would extend matrix. With a formal
validity method that verifies the dimensions.

I think QString and QByteArray should just go to plain old character vectors
though. I kind of see a string as a primitive.

On Wed, Jan 20, 2010 at 12:53 PM, Michael Lawrence <michafla at gene.com>wrote:

>
>
> On Wed, Jan 20, 2010 at 11:35 AM, Deepayan Sarkar <
> deepayan.sarkar at gmail.com> wrote:
>
>> On Wed, Jan 20, 2010 at 11:11 AM, Michael Lawrence
>> <lawrence.michael at gene.com> wrote:
>> > Well, the paper was a little tough for me to grok. But anyway, I think
>> we
>> > need a consistent type conversion policy. When Qt always treats a class
>> as a
>> > pointer (e.g. QObjects), it's pretty clear that we need to do the same.
>> For
>> > value types, it's more complicated. Qt uses values to avoid the
>> > complications of memory management (as with QImage) or to avoid memory
>> > allocation overhead for small types (like QPen).
>> >
>> > From the R user's perspective, memory management is largely irrelevant.
>> But
>> > given the choice of an opaque pointer or a native R type, I think the
>> user
>> > would choose the latter. However, I agree with you that there is not
>> always
>> > such an obvious mapping. QImage is a good example. Would the user really
>> > expect a huge matrix of pixels? The primary use of a QImage is to
>> display
>> > it, not to manipulate its pixels, but the same is not true for a
>> QMatrix, or
>> > QRect, etc. For those classes, the primary interest is in the values
>> (the
>> > parameters of QMatrix, the coordinates of the rectangle). There it may
>> be
>> > convenient to perform the conversion up-front, and thus making the
>> interface
>> > tighter between R and Qt.
>> >
>> > That said, there may be cases where one does not want to perform the
>> > conversion. The collection types (QMap, QList, QVector, etc) have fairly
>> > obvious analogs in R vectors. The problem is that there is overhead to
>> the
>> > conversions. If the collection is large, the user may wish to pass
>> opaque
>> > pointers.
>> >
>> > In theory, it's possible to make this optional. That is, the user could
>> as
>> > part of a MethodCall request that high-level conversion be avoided. This
>> > would not be that hard to implement. The qinvoke() function could take
>> an
>> > extra parameter (.convert or something) that would tell the MethodCall
>> > object to avoid special type handlers for the return value.
>> >
>> > I will say that I've never encountered a case with RGtk2 where the
>> > collections are too large to convert. But this Qt interface is more
>> general
>> > and so it might come up more often. I think I'll wait for a use-case.
>>
>> Sounds good.
>>
>> Just to be clear, when you convert to a native R object, would they
>> still have a class indicating that they represent something from Qt?
>> So Qt$QFont() would be a R list, but with class "QFont"?
>>
>>
> This is correct. The classes would be QFont, RQtValue (for the $ method),
> and RQtObject for the Ops method, %<<% and other operators.
>
> Michael
>
>
>> -Deepayan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.r-forge.r-project.org/pipermail/qtinterfaces-devel/attachments/20100121/53764195/attachment.htm