in reply to Help: 5.6.1: XSUB and AUTOLOAD

I don't know why this changed between versions of Perl. However, my first reaction on seeing what you were doing (without knowing what the problems were) was "Oh, you should define your AUTOLOAD in Perl and have it dispatch to the XS code." And that would probably solve your problem.

The reason that I thought that was that I feel that you should write as much of your code as possible in Perl and as little as possible in C/XS. Code you write in C/XS is much more likely to break between versions of Perl, is usually quite a bit less robust (on things like tied or "magic" variables and often even on much simpler stuff), and is harder to write/read/understand/debug/extend/work-around/etc. than the equivalent Perl code.

        - tye (but my friends call me "Tye")
  • Comment on (tye)Re: Help: 5.6.1: XSUB and AUTOLOAD

Replies are listed 'Best First'.
Re: (tye)Re: Help: 5.6.1: XSUB and AUTOLOAD
by Anonymous Monk on Jul 20, 2001 at 09:21 UTC
    Well, the whole story goes like this: there used to be a package PerlQt which I happened to like a lot. However the guy who wrote it seems to have abandoned his baby. So I tried to bring it up to date -- when I found that 99% of the code relies on AUTOLOAD, kinda like I described before. Yes, my first reaction was the same: dispatch from Perl, and this is the fix that works for me now (I am yet to try to get in touch with the author again on this) -- however, it means having tons of "use Qt::ThisAndThat;" statements, whereas XS allowed to have a single AUTOLOAD for everything. I have a few ideas how to patch this, however first I wanted to be sure I am not doing something stupid.

    Thanx for reply, anyway. I posted to a couple of newsgroups too, and it looks like not to many people are intimately familiar with the topic.

    Best,

    Mishka

[reply]

      Well, I was thinking more along the lines of: 

      sub AUTOLOAD {
    AutoLoad( $AUTOLOAD, @_ );
}

      [download]
      and have AutoLoad() be the XS routine. Passing in $AUTOLOAD could be optional since you probably already have code that knows how to fetch that.

      But maybe something that simple wouldn't be enough to overcome the bug you hit. (:

              - tye (but my friends call me "Tye")
[reply]
[d/l]
        That's exactly what I tried to do.

        As I said, the thing is, PerlQt is "many packages in one", so one needs to define this for, e.g. Qt.pm, Qt/Object.pm, Qt/Application.pm, and so on. Also, simple code like 

        use Qt;
import Qt::app;
$hello = Qt::PushButton->new('Hello');
$hello->resize(100, 30);
$app->setMainWidget($hello);
$hello->show();
exit $app->exec();

        [download]

        becomes 

        use Qt;
use Qt::Object;
use Qt::Application;
use Qt::PushButton;
use Qt::Font;
import Qt::app;
$hello = Qt::PushButton->new('Hello');
$hello->resize(100, 30);
$app->setMainWidget($hello);
$hello->show();
exit $app->exec();

        [download]
        and more complex examples end up having dozens of "use" statements, which is kinda inconvenient. The original piece of code was pretty inventive about this: all Qt::*::AUTOLOAD methods were directed (newXSUB'ed) to the same place, so a single "use Qt" was enough. Right now I am thinking of overloading "new" and "DESTROY" methods of each class with what used to be "AUTOLOAD". In the original code, AUTOLOAD on each object was used only once, and whan it did, it loaded (newXS'ed) the real methods (I think the guy did that for optimization). Since every object in PerlQt has both "new" and "DESTROY", the "fake new" e.g. procedure would be overriden immediately after it is called. This approach seems to work better, although there are some subtleties that I have to take care of.

        This all brings me to one thing: my God, how I wish Perl5 along with perlguts soecs was standartized!

        best,

        Mishka

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom