I&#39;m now thinking we&#39;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.<br>
<br>If we did that though, we&#39;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.<br><br>I think QString and QByteArray should just go to plain old character vectors though. I kind of see a string as a primitive.<br>
<br><div class="gmail_quote">On Wed, Jan 20, 2010 at 12:53 PM, Michael Lawrence <span dir="ltr">&lt;<a href="mailto:michafla@gene.com">michafla@gene.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Wed, Jan 20, 2010 at 11:35 AM, Deepayan Sarkar <span dir="ltr">&lt;<a href="mailto:deepayan.sarkar@gmail.com" target="_blank">deepayan.sarkar@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, Jan 20, 2010 at 11:11 AM, Michael Lawrence<br>
<div>&lt;<a href="mailto:lawrence.michael@gene.com" target="_blank">lawrence.michael@gene.com</a>&gt; wrote:<br>
</div><div><div></div><div>&gt; Well, the paper was a little tough for me to grok. But anyway, I think we<br>
&gt; need a consistent type conversion policy. When Qt always treats a class as a<br>
&gt; pointer (e.g. QObjects), it&#39;s pretty clear that we need to do the same. For<br>
&gt; value types, it&#39;s more complicated. Qt uses values to avoid the<br>
&gt; complications of memory management (as with QImage) or to avoid memory<br>
&gt; allocation overhead for small types (like QPen).<br>
&gt;<br>
&gt; From the R user&#39;s perspective, memory management is largely irrelevant. But<br>
&gt; given the choice of an opaque pointer or a native R type, I think the user<br>
&gt; would choose the latter. However, I agree with you that there is not always<br>
&gt; such an obvious mapping. QImage is a good example. Would the user really<br>
&gt; expect a huge matrix of pixels? The primary use of a QImage is to display<br>
&gt; it, not to manipulate its pixels, but the same is not true for a QMatrix, or<br>
&gt; QRect, etc. For those classes, the primary interest is in the values (the<br>
&gt; parameters of QMatrix, the coordinates of the rectangle). There it may be<br>
&gt; convenient to perform the conversion up-front, and thus making the interface<br>
&gt; tighter between R and Qt.<br>
&gt;<br>
&gt; That said, there may be cases where one does not want to perform the<br>
&gt; conversion. The collection types (QMap, QList, QVector, etc) have fairly<br>
&gt; obvious analogs in R vectors. The problem is that there is overhead to the<br>
&gt; conversions. If the collection is large, the user may wish to pass opaque<br>
&gt; pointers.<br>
&gt;<br>
&gt; In theory, it&#39;s possible to make this optional. That is, the user could as<br>
&gt; part of a MethodCall request that high-level conversion be avoided. This<br>
&gt; would not be that hard to implement. The qinvoke() function could take an<br>
&gt; extra parameter (.convert or something) that would tell the MethodCall<br>
&gt; object to avoid special type handlers for the return value.<br>
&gt;<br>
&gt; I will say that I&#39;ve never encountered a case with RGtk2 where the<br>
&gt; collections are too large to convert. But this Qt interface is more general<br>
&gt; and so it might come up more often. I think I&#39;ll wait for a use-case.<br>
<br>
</div></div>Sounds good.<br>
<br>
Just to be clear, when you convert to a native R object, would they<br>
still have a class indicating that they represent something from Qt?<br>
So Qt$QFont() would be a R list, but with class &quot;QFont&quot;?<br>
<font color="#888888"><br></font></blockquote></div></div><div><br>This is correct. The classes would be QFont, RQtValue (for the $ method), and RQtObject for the Ops method, %&lt;&lt;% and other operators. <br><br>Michael<br>
 <br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888">
-Deepayan<br>
</font></blockquote></div><br>
</blockquote></div><br>