In your connect method, there really isn't a need for the find variable at all. You can use an anonymous hash instead.

sub connect{
    my $class = $_[0];
    
    if (-e "$_[1]"){ 
    
        my $object = {
            connect => $_[1],
            prepare => '',
            select => '',
            where => {},      #anonymous hash reference
            column => '',
            records => '',
        };
                   
        bless $object, $class;
        return $object; 
    }
    else{
        die "file: $_[1] doesn't reside at path\n";
    }            
}
[download]

Also, you don't have to put it into a local variable in order to assign something to it:

$self->{where}->{name}='test';
[download]

Ditto the stuff about exporter. You may have picked it up if you started a package using h2xs -XA foo. But in my experience the exporter isn't needed for objects. (And when it is the use base Exporter; eliminates a bunch of lines.)

Hi,

First, a quick note: you do not need to do any of the Exporter stuff at the top. You probably want connect called like:

Excel::Tabbed->connect('file');
#  or
connect Excel::Tabbed 'file';
[download]

In either case, you are calling connect through the package Excel::Tabbed. So, you do not want to export it.

What you are doing is ok, but could be cleaned up a bit:

....
my ($self,$args) = @_;  # Should that be @args, not $args
my $find = $self->{where};            
$find->{name} = 'test'; # You didn't need the {} around find.
[download]

So this looks fine. Are you having problems? You don't describe how it is not working.

TedYoung,
Your statement: First, a quick note: you do not need to do any of the Exporter stuff at the top without an explanation might be a little confusing. The following is more to benefit others than you - even then it is an oversimplification.

Exporter is a useful tool that allows subroutines defined in another namespace to become part of your namespace when you use that module. There are issues to be concerned with like which ones to export by default, name collisions, etc. When using OO however, it is not necessary to export any subroutines that will be used as methods on that object.

Of course there is a lot more to the story and spending time RTFMing helps turn the scary black magic into ordinary perl-fu.

Cheers - L~R

well I guess I am retarded... removed the brackets around find and it works. wonder how I missed that one. I am using

Excel::Tabbed->connect('file');
[download]

the reason for the export I was trying to

use Excel::Tabbed;
my $thingy = connect('file');
[download]

thanks for you assistance.

I thought that you might be shooting for connect('file'). That won't work, because you won't be handed a package name as your first param. The most common approach is Excel::Tabbed->connect('file');

Ted Young

($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)

• Spreadsheet::ParseExcel
• Spreadsheet::WriteExcel
• Excel::Template

If you're working using OLE automation, there are a number of nodes on this site for how to hook Win32::OLE to Excel (and Word, for that matter).

What I'm getting at is that it may be that the problem you're attempting to solve may already be solved.

you are abosolutely right BUT

1. I am distributing this module in a application. I dont want to place the entire cpan volume in my application.

2. All I need it to do is read a tabbed file so installing over 8 modules to just read a file is crazy.

3. If a problem occurs tracing through tons of modules to find out exactly what is wrong is nuts. 4. Because it gives me experience and increases my perl knowledge.... I hope :)

1. Use PAR to distribute Perl applications. That will take care of all dependencies, including distributions with compiled components.
2. If all you need to do is read a tab-delimited file, then you should be using Text::xSV. It is PurePerl and deals with a number of issues I'm sure you haven't considered.
3. If a problem occurs, 99% of the time the fault will lie in your code, not in code from CPAN. That's because the code from CPAN has been tested in more situations that you will ever have the misfortune of running into.
4. Increasing your Perl knowledge is a wonderful thing. However, what I would not like to see you distribute an application with bugs that could have been avoided if you had simply chosen to use a well-tested module instead of rolling your own. CPAN exists for a reason; use it!

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.