There's already a feature where if you try to load a perl module with a
number, it checks the version of the module that's installed. Even if you
are trying to cheat around that by using quotes, it would be confusing to
potential users. I would suggest using a more stringish string like
use Qt ('qt4');
if you want to go that route. Or even,
use Qt::Qt4;
which I think would be more Perlish.
On Tue, May 26, 2009 at 7:51 AM, Jonathan Yu <[email protected]>wrote:
> Hi:
>
> Given all the discussion from everyone else, it seems that the main
> idea is to keep the bindings separate from each other, so they don't
> conflict with past/future programs.
>
> So maybe what we need is a central Qt module, but one where we will be
> able to do something like:
>
> use Qt ('4');
>
> to load Qt version 4's bindings, maybe under a different namespace,
> like Qt4. Then that module could do some magic to re-map itself under
> Qt's main namespace, so upgrading between mostly compatible API's
> would be as trivial as switching the use Qt statement and bumping it
> up, then dealing with the "no such function" warnings (hopefully
> people don't often completely change the semantics of a given
> function).
>
> This definitely warrants some more thought & discussion.
>
> Cheers,
>
> Jonathan
>
> On Tue, May 26, 2009 at 4:05 AM, Peter Pentchev <[email protected]> wrote:
> > On Mon, May 25, 2009 at 06:00:12PM -0700, Eric Wilhelm wrote:
> >> # from Jonathan Yu
> >> # on Monday 25 May 2009:
> >>
> >> >I'd like to remove the Qt module from CPAN, or be able to take it
> >> > over.
> >>
> >> Hi Jonathan,
> >>
> >> That's a good question in general, but for Qt4, I'm inclined to say that
> >> a better approach would be to use the 'Qt4::' namespace.
> >>
> >> >I'm working with someone else on perlqt4 bindings for my Google Summer
> >> >of Code project, and the currently available version of Qt is from
> >> >1997 and of little use to anybody. (See: code.google.com/p/perlqt4)
> > [snip]
> >>
> >> From my tinkering with it thus-far, it appears that Qt3 and Qt4 are
> >> quite different APIs. That is, current Perl code written for Qt (3)
> >> won't "just work", right?
> >
> > Errrrrm... I don't think that the Qt module written in 1997 would
> > support Qt 3 :)
> >
> > Actually, from the module's README file:
> >
> > This release, PerlQt 0.03, is distributed under the LGPL and requires
> > Qt-1.1 and Perl 5.004 (or a beta version). I have only successfully
> > compiled PerlQt myself on my own RedHat Linux 4.0 system with a 2.0.28
> > kernel, running Perl-5.00390, which is a beta-release of Perl-5.004.
> >
> > I really don't think anyone ought to worry about backwards compatibility
> > with the Qt module currently on CPAN :)
> >
> > G'luck,
> > Peter
> >
> > --
> > Peter Pentchev [email protected] [email protected] [email protected]
> > PGP key:
> > http://people.FreeBSD.org/~roam/roam.key.asc<http://people.FreeBSD.org/%7Eroam/roam.key.asc>
> > Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
> > This would easier understand fewer had omitted.
> >
>
--
Check out my LEGO blog at http://www.brickpile.com/
View my photos at http://flickr.com/photos/billward/
Follow me at http://twitter.com/williamward
