I hate really short modules. They should be pasted into your code. It makes it easy to see what it's doing, and it eliminates a file operation. But how about when you install a new version of Perl and you want the latest version of the module to be used? I'm way ahead of you, buddy. I got something better--auto-updating snippets.

I figure I'll do it will a source filter, but I don't know how yet. I'd make "snippet" a new function. It would take two arguments:

Arg1: The serial number of a snippet from the official, online (hopefully with a load-balanced network of mirrors) snippet library, or your private snippet library. The serial number would include an extension indicating the version number.

Arg2: "update" or blank to indicate whether you want to check for an update or whether you included the snippet that you want used. If blank, the serial number would act as a comment, telling you where the snippet came from and reminding you that you could make it auto-update. The update feature would be recommended for occasional use or a local snippet library that itself would need to be updated and would hopefully become core.

The "snippet" function could optionally be followed by the current or prior version of the snippet itself. If the update parameter was used, the function would be replaced with the snippet from the library, and if you included the snippet in the code, it would be deleted. If the serial number refers to an old version, an alert wll be issued.

If I do this, you all must contribute to my snippet library (recommended max length per snippet will be announced), and you all must use it.

Replies are listed 'Best First'.
Re: Auto-updating snippets.
by blokhead (Monsignor) on Jul 16, 2004 at 00:48 UTC
    Looks like you hit the nail on the head as to why you would want to abstract a module to a file: because you can maintain it in one place. One subroutine called from many code points, one module used by many programs, etc... One place to make changes!
    They should be pasted into your code. It makes it easy to see what it's doing
    If the sub/module is named reasonably and it has a good interface, it's trivial to figure out what the calling code is doing, and will take much less space than a cut-and-paste job. Not everything has to be named "foo" ;) ..
    I'd make "snippet" a new function. It would take two arguments:
    How is snippet(12345678) easier to understand than a well-thought-out modular interface?
    and it eliminates a file operation.
    Is checking a remote site for updates any better? It sure seems less safe. I know that you as a snippet server administrator would have the best of intentions, but someone more malicious could spoof the site and send back any snippet. So now you're probably looking at doing cryptographic signatures, etc, before this would be taken seriously. Sounds like a lot to save a file operation.

    It sounds like your problem with these small modules is not their size, but perhaps a dumb interface. You actually propose to solve a completely orthogonal problem, that of keeping code up-to-date. This does seem like a good problem to look at. Personally, I'd prefer something that planted itself in @ISA and checked CPAN for module auto-updates (I'm sure there are many tools like this out there already). This would happen behind the scenes of my current use statements, so would be of minimal impact.

    To solve your original beef with these small modules, it's fine to tailor them to your own needs. Cut and paste the snippets into your code if they're trivial. Write your own with a better interface. Bug the original author to do it ;)

    If I do this, you all must contribute to my snippet library (recommended max length per snippet will be announced), and you all must use it.
    Charming.

    blokhead

[reply]
[d/l]
Re: Auto-updating snippets.
by TilRMan (Friar) on Jul 16, 2004 at 00:44 UTC

    While I disagree with the idea of replacing modules with snippets, the auto-update system itself might be interesting. It sounds like search-and-replace on crack, with syntactical sugar for Perl parsing. I can easily imagine using such a beast for bandaging broken code long enough for me to do proper refactoring.

    I assume that the system would be smart enough to find snippets on its own, so that old scripts can be udpated. In other words, if you have to say #This is snippet number 927307, it'll never work.

    The system becomes quite valuable, IMHO, when you starting thinking in terms of idioms instead of snippets. For example, I propose the first "snippet" should be:

    $|++

    and also propose the first update (to same snippet):

    $| = 1

    See, among other discussions, Re: Poor Perl Idioms Explained (except not really).

    Update: Wassercrats: I accept your terms, with the following addition: If I contribute, you must implement it. :-)

[reply]
[d/l]
[select]
Ingenious
by sleepingsquirrel (Chaplain) on Jul 16, 2004 at 04:25 UTC
    Initiate an investigation into Inline::Files for implementation inspiration.

    -- All code is 100% tested and functional unless otherwise noted.
[reply]
Re: Auto-updating snippets.
by dws (Chancellor) on Jul 16, 2004 at 00:19 UTC

    ... and it eliminates a file operation.

    Is this really a measurably noticeable problem for you? If so, how many modules are we talking about?

[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Auto-updating snippets.
by gellyfish (Monsignor) on Jul 16, 2004 at 11:41 UTC

    Sounds like you might be in the market for the inline program that we use on the NMS project.

    /J\

[reply]
Re: Auto-updating snippets.
by Solo (Deacon) on Jul 16, 2004 at 03:02 UTC
    How will each Perl program get the 'snippet' function to begin with? How would you release updates to the 'snippet' function?

    --Solo
    --
    You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
[reply]
      How will each Perl program get the 'snippet' function to begin with? How would you release updates to the 'snippet' function?

      Clearly, that's going to be a really long piece of code, so it'll be justified as a full module. :-)

      --
      F o x t r o t U n i f o r m
      Found a typo in this node? /msg me
      % man 3 strfry

[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Auto-updating snippets.
by exussum0 (Vicar) on Jul 16, 2004 at 20:25 UTC
    Hard drives can churn fast enough now-a-days that unless your perl program is over a meg, I doubt you'll notice much during loading.

    I never want my packages autoupdated unless it's a standalone product that's understood to be updated as such. For instance, if there's a bug in the package and i code around the bug, once the package fixes said bug, it may break my code. I may rather the old version due to unreconcilable issues with the newer one.

    Change management is not something that's easy to automate. All we can do is create tools to make it easier.

    Bart: God, Schmod. I want my monkey-man.

[reply]
Re: Auto-updating snippets.
by fraktalisman (Hermit) on Jul 19, 2004 at 21:06 UTC
    If I do this, you all must contribute to my snippet library

    Seriously: there are enough people who do not even know how to contribute to CPAN. Centralization can be a good thing! If I need some extra functions I visit CPAN. If I'd have the time to contribute some good code to the perl community, I'd post it here and maybe later make a module of it. CPAN is one place for everyone to check.

    There have been some recent discussions about improving modules and their organization. To me, this seems to be a more valuable approach than designing a new "snippet" system.

    Where could I use your new system? I'm quite convinced, most of my customers' webspace providers would not install it. They have lots of standard modules installed though. So even if I'd agree that I "must use it", I would not be able to.

[reply]

Back to Meditations