Try $self= [@_]; [(update2) in place of $self= \\@_;].

Update: I'd say more but I can't figure out what

I wasnīt able to "pass this reference" returned from Parser to the reference member of the Entry object.

Someone here at the Chatterbox told me, that this indeed isnīt possible

Anyway, I wouldn't ever put \@_ into an object as changes to @_ would be reflected in the object and I'm not sure what changes Perl itself might make to @_ when the subroutine exits. Also, the elements of @_ are aliases to the arguments passed in (that is \$_[0] == \$arg0) so changing $_[0] changes the variable (in the caller) that was passed in and vice versa. But [@_] creates a new anonymous array and copies the elements of @_ into it and so shouldn't suffer from these two problems.

But none of that explains to me why \\@_ would work. /:

> Try $self=[@_];

Where? :-)

What I mean with "pass this reference" is actually "clone a reference". Again assume you have a parser and this parser is filling you a structure (basically a list). You let your parser return a reference to the structure created and you would like your Entry Object to store THAT Reference.

This seems not possible. BTW: You throw up an interesting point:

>Anyway, I wouldn't ever put \@_ into an object as changes...

How do you declare an object whose only element is a reference to a list (or hash for that matter)?

Thanks Richard

You're confusing the implentation of the object and the attributes of that object.

If you want to declare an object which is implented as a list, I'd do something like:

sub new {
    my $class = shift;
    my $self = [@_];
    bless $self, $class;
    return $self;
}

sub getList {
    my $self = shift;

    if (wantarray) {
        return @$self;
    else {
        return [@$self];
    }
}
[download]

If you wanted to have a class which had only one attribute and that attribute was a list, I'd do something like:

sub new {
    my $class = shift;

    my $self = {};
    bless $self, $class;

    $self->{LIST} = [@_];

    return $self;
}

sub getList {
    my $self = shift;

    if (wantarray) {
        return @{$self->{LIST}};
    else {
        return [@$self->{LIST}];
    }
}
[download]

Then, you would add setters as well. However, we already have something like this, in the form of tie and Tie::Array (and its cousin Tie::Hash). Check those out.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

I think your confusion lies in the implementation details. You're not seeing the forest for the trees. Step back a moment and let's design this, then implement it.

You have some container object. That container object shouldn't care what objects it contains. More specifically, it shouldn't care how those objects are implemented.

This would mean that instead of doing @{$self->{$key}}, you would do something like @{$self->{$key}->getList}. This allows the contained object to determine how to store itself. In addition, it allows for your container to store more than one type of object.

So, what this means is you have to create a bunch of methods that will do stuff, like get the list being stored in the inner object.

Does this make sense so far?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.