Use packages?

Ovid on 2009-08-11T22:23:53

Since modules is taken, I was thinking about packages to do this:

#use Spreadsheet::ParseExcel::Workbook;
#use Spreadsheet::ParseExcel::Worksheet;
#use Spreadsheet::ParseExcel::Font;
#use Spreadsheet::ParseExcel::Format;
#use Spreadsheet::ParseExcel::Cell;
#use Spreadsheet::ParseExcel::FmtDefault;

use packages 'Spreadsheet::ParseExcel' => qw(
    Workbook
    Worksheet
    Font
    Format
    Cell
    FmtDefault
);

No idea if people would really care, but I like the cleaner syntax. Or maybe as a new feature with 'aliased':

use aliased 'Spreadsheet::ParseExcel', import => [qw(
    Workbook
    Worksheet
    Font
    Format
    Cell
    FmtDefault
)];

Seems an uncomfortable overloading of aliased, but it could be handy.


What about 'from'

Arador on 2009-08-11T22:52:47

What about from?

use from 'Spreadsheet::ParseExcel' => qw(
        Workbook
        Worksheet
        Font
        Format
        Cell
        FmtDefault
);

Or something else that looks more like English.

Shrug...

Matts on 2009-08-11T23:29:20

Personally I don't think it's really any cleaner. You've just hidden your meaning behind another statement, another module that the next maintainer has to go and read the docs for to figure out what it does. Sure it's a bit of extra typing, but you only do it once per file.

Thumbs down

Alias on 2009-08-12T04:47:23

I think it adds complexity and reduces clarity just to save a few characters.

Simpler syntax

davegaramond on 2009-08-12T05:09:25

Actually I kinda like it since I hate all repetitions/duplications and regard them as evil.

But it needs the simplest syntax possible to avoid burning extra brainpower. Somehow all the above examples don't cut it.

How about supporting Unix shell's feature? And how about the name multi or many? use many 'A::{B,C}::{D,E}';

Re:Simpler syntax

davegaramond on 2009-08-12T05:12:40

Another example: use many 'A::B::*'; . Having to require '/somedir/*.pl' comes up from time to time for me, though quite rarely.

Re:Simpler syntax

Aristotle on 2009-08-12T09:34:28

I hate all repetitions/duplications and regard them as evil.

Please see Incidental Redundancy.

Sorry

vek on 2009-08-12T05:16:35

The original code is instantly understandable and the intent clear. Now when someone reads your new packages code, they have to pause for a few seconds to figure out what it does and why. I'm not entirely sure that extra speed bump is worth it.

Hmm...

xsawyerx on 2009-08-12T08:12:12

with qw(
    Teleweb::Mapper::OS
    Teleweb::Mapper::Ifaces
    Teleweb::Mapper::MainIP
    Teleweb::Mapper::HostingType
    Teleweb::Mapper::RAM
    Teleweb::Mapper::CPU
    Teleweb::Mapper::Apps
    Teleweb::Mapper::Services
    Teleweb::Mapper::Server_app
);

Would be:

# extrapolates from Teleweb::Mapper
use from 'Teleweb::Mapper' => qw(
  OS Ifaces MainIP HostingType RAM CPU Apps Services Server_app
);

restricted ability to search

jmm on 2009-08-12T14:04:47

find srctree -type f | xargs grep Spreadsheet::ParseExcel::Font

The suggested kind of shorthand makes it really hard to do custom searches of your code base, such as for all the code that might happen to use a particular module.  (There might be many modules named mumble::Font - when you separate Spreadshht::ParseExcel unto a separate line from Font you lose the ability to find that unique name using generic tools.

Wildcard?

djberg96 on 2009-08-13T00:34:43

use Spreadsheet::ParseExcel::*;

What, too Java?

Re:Wildcard?

Ovid on 2009-08-13T06:12:39

Something I had considered once but was quickly talked out of. Basically, even many Java people admit that this construct was a mistake. You're not being explicit about what you want and it's therefore unclear what you get. Hell on maintenance programmers.

Module::Find

jdv on 2009-08-13T14:36:08

Why reinvent the wheel?

Re:Module::Find

Ovid on 2009-08-13T15:03:53

Same problems as listed in this proposal. I think, given the comments, I won't do it. Other can if they want :)