Ah OK, thanks for the feedback. I'll check it out and see what makes sense,
<br>
then I&#39;ll ask for comments in #dbix-class.
<br>
On Jul 1, 2014 5:52 AM, &quot;Peter Rabbitson&quot; &lt;notifications@github.com&gt; wrote:
<br>

<br>
&gt; Ok. While on the surface this looked like a trivial thing it actually
<br>
&gt; turned out to be much more involved. These pieces were committed to
<br>
&gt; current/for_cpan_index so far:
<br>
&gt;
<br>
&gt;    - Some refactor of the docs 293a924
<br>
&gt;    &lt;https://github.com/dbsrgits/dbix-class/commit/293a9242a&gt; and
<br>
&gt;    downright purge of useless deps 77a6448
<br>
&gt;    &lt;https://github.com/dbsrgits/dbix-class/commit/77a6448dc&gt;
<br>
&gt;    - An easier-to-follow version of your datetime example a0a0da0
<br>
&gt;    &lt;https://github.com/dbsrgits/dbix-class/commit/a0a0da0ae&gt;
<br>
&gt;
<br>
&gt; The remaining piece is pushed to wip/moo_resultsets_docs, and has the
<br>
&gt; following outstanding problem that needs attention: The Moose example has
<br>
&gt; only BUILDARGS yet the Moo example has both BUILDARGS and FOREIGNBUILDARGS.
<br>
&gt; Please investigate, see which one is right and resubmit changes to 15c43cf
<br>
&gt; &lt;https://github.com/dbsrgits/dbix-class/commit/15c43cfda&gt; (the example
<br>
&gt; code has to be flawless, as the cargocult of this will be high)
<br>
&gt;
<br>
&gt; As an aside - there was an issue brought up yesterday on IRC concerning
<br>
&gt; Moose-based Result classes (not ResultSet classes). Perhaps a separate
<br>
&gt; patch to document that inconsistency would also be of use:
<br>
&gt;
<br>
&gt; &lt;corgifex&gt; ribasushi: 1) is using Moose with DBIx::Class supported at all? 2) is MooseX::NonMoose + extends &#39;DBIx::Class::Core&#39; the right way?  3) is &#39;lazy&#39; a sensible workaround for DBIx::Class not calling the constructor? 4) is there a better way to do this?
<br>
&gt; &lt;ribasushi&gt; corgifex: in this case it depends what you mean by &quot;supported&quot;
<br>
&gt; &lt;ribasushi&gt; corgifex:  the core DBIC result class has 2 separate constructors, which was a good idea at the time it was written, so if you expect constructor-based thingies to work, you will have to do some duct taping
<br>
&gt; &lt;ribasushi&gt; corgifex: and as you already properly noted default non-lazy attributes do not work without constructor-based instantiation
<br>
&gt; &lt;ribasushi&gt; corgifex: so it all depends on &quot;how do you want things to interface&quot; - it will be a tradeoff either way, and you need to decide where to make it
<br>
&gt;
<br>
&gt; Cheers and thanks again for looking into this
<br>
&gt;
<br>
&gt; —
<br>
&gt; Reply to this email directly or view it on GitHub
<br>
&gt; &lt;https://github.com/dbsrgits/dbix-class/pull/49#issuecomment-47637403&gt;.
<br>
&gt;

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br>Reply to this email directly or <a href="https://github.com/dbsrgits/dbix-class/pull/49#issuecomment-47650130">view it on GitHub</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/302594__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxOTgzNzMzMiwiZGF0YSI6eyJpZCI6MzU3ODkwMTV9fQ==--b3c52b5ff57d62de8b5dd38267939eef0f3d7339.gif" width="1" /></p>