Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Mail::Box Mailing List 15 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • 5.00503 (Score:3, Interesting)

    by Matts (1087) on 2002.06.10 8:03 (#9395) Journal
    What keeps you restricted to 5.6.1? Is it regexp features, our() or "use base" or something else?

    There are an awful lot of people still on 5.00503.
    • Furthermost it is the need for weak references. It's exceptionally easy to create unDESTROYable data-structures with that large a module whereas it is almost impossible not to do so. Anyway, we are approaching Perl 5.8.0 with already one release-candidate out. I think it is time for module authors to start using all the new cool features from 5.6.x onward.

      • Re:5.00503 (Score:5, Insightful)

        by Matts (1087) on 2002.06.10 8:43 (#9401) Journal
        If it helps, I have a technique (I didn't invent it - it's an old technique) in XML::XPath that allows you to avoid circular references without changing your code significantly. With a small patch it could be made to use weakrefs on 5.6.1 - I've just never gotten around to it.

        It's all good and well telling people that module authors should use 5.6.1, and for sure there are some nice features (open(my $fh) being one, weakrefs being the other), but persuading sysadmins to upgrade is a whole other issue. Especially when up until now FreeBSD has shipped with 5.00503.

        • Re:5.00503 (Score:2, Interesting)

          by jzawodn (27)
          So, what's the secret? I've encountered the need for weak refs and wondered about any clever workarounds.

          Or is is just best to read the code in the hopes of finding it?

          • Re:5.00503 (Score:3, Informative)

            by Matts (1087)
            It basically uses indirect objects. Instead of having two nodes - a parent and a child, you have a parent, a proxy, and a child. The parent points to the proxy, the proxy points to the child, and child points to the proxy. When the parent gets garbage collected, it informs the proxy to sever it's link to the child, thus breaking the circular reference.

            The clever thing about XML::XPath's code is that it manages to do this flexibly enough that by switching just one flag it can work in either the indirect obj

          • Re:5.00503 (Score:2, Informative)

            by markov (3225)
            Why complicated work-arounds when Perl supports weak references? OK, you want portability... and miss all the other nice new features as well?
            One way to avoid need for weak references is to have all objects register/unregister themselves in a hash. Other objects refer to that object by the key in that hash. The code will be clumpsy but it will work.
  • I released Mail::LocalDelivery the other day, a Mail::Audit spin-off and local delivery agent in pure Perl. It's not as fully featured as Mail::Box but does one job and, if I may say so, does it bloody well. (Thanks in part to Meng Wong's work on it.)
    • Not as fully featured? ;-) I think it is something entirely different.
      • I think it is something entirely different.

        It's for receiving and storing messages, which is some of what Mail::Box claims to do. But year, it's a different beast - but still part of the whole handling-mail-with-Perl experience.

        • Simon says:
          It's for receiving and storing messages, which is some of what Mail::Box claims to do. But year, it's a different beast - but still part of the whole handling-mail-with-Perl experience.

          Indeed. I have seen that Mail::Audit has grown into something quite big so you started to modularize it a little. This is good, I once had to patch Mail::Audit (the double from-line bug, that was)...not a nice experience. ;-)
          One problem, however, that I see with mail-related Perl-modules: a lot of people ha
      • The main problem is not that the current modules related to e-mail deliver too little functionality: there is plenty of it. IMHO, the problem is that it is fragmented into too many packages with different coding and documentation styles, and without general design. And all te time new weird fragments appear, in strange name-spaces.
        Simon, it would suit you to come to my introductory talk on YAPC::Europe. Maybe it is more useful to combine forces in stead of simply ignoring the other's work. Or have a lo
        • Simon, it would suit you to come to my introductory talk on YAPC::Europe.

          Sorry, but YAPC America is my last Perl conference.

          Maybe it is more useful to combine forces in stead of simply ignoring the other's work.

          Interesting that you're saying that to me and not to Mark. :) But yeah, NIH syndrome is a big problem with the Perl community, myself included. We're becoming too ego-dominated. :(

          • >> Maybe it is more useful to combine forces in stead of simply ignoring the other's work.
            > Interesting that you're saying that to me and not to Mark. :)
             
            Would be silly to talk to myself, don't you think?
  • Just a thought from the top of my head: what about compatibility of the Mail::Box API with one of the IMAP interfaces? I'd really love to be able to handle both via the same interface, just switching one configuration line...
    • Someone is already experimenting with it. The target is to implement an read-only extension Mail::Box::IMAP, which behaves like other folders. As far as I can see now it will not be too hard to do. Volunteers? Please post to the mailinglist.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.