How can I overload the build in array type?
Ilias Lazaridis
overload] provides functionality for operators:
{{{
#!perl
use overload
'+' => \&myadd,
'-' => \&mysub;
# etc
...
}}}
is there a similar module to overload the classes of build in types
(like array), something like:
{{{
#!perl
use typeoverload
'@' => 'My::Array',
'%' => 'My::Hash';
# etc
...
}}}
-
(this question was already discussed within another topic. Just
posting a own thread to be sure the question gets the visibility on
it's own)
.
bugbear
> perl [http://search.cpan.org/~nwclark/perl-5.8.8/lib/overload.pm
> overload] provides functionality for operators:
>
> {{{
> #!perl
> use overload
> '+' => \&myadd,
> '-' => \&mysub;
> # etc
> ...
>
> }}}
>
> is there a similar module to overload the classes of build in types
> (like array), something like:
>
> {{{
> #!perl
> use typeoverload
> '@' => 'My::Array',
> '%' => 'My::Hash';
> # etc
> ...
>
> }}}
I would thoroughly recommend not doing this.
I don't think I've *ever* seen a use of operator
overleading in C++ (which I was exposed to for a
good while) that made the code clearer or better.
It effectively hide the fact that user code is
being called from the reader of the code.
Blech.
BugBear
Ilias Lazaridis
wrote:
> Ilias Lazaridis wrote:
> > perl [http://search.cpan.org/~nwclark/perl-5.8.8/lib/overload.pm
> > overload] provides functionality for operators:
>
> > {{{
> > #!perl
> > use overload
> > '+' => \&myadd,
> > '-' => \&mysub;
> > # etc
> > ...
>
> > }}}
>
> > is there a similar module to overload the classes of build in types
> > (like array), something like:
>
> > {{{
> > #!perl
> > use typeoverload
> > '@' => 'My::Array',
> > '%' => 'My::Hash';
> > # etc
> > ...
>
> > }}}
>
> I would thoroughly recommend not doing this.
thank you for your gentle recommendation.
but the main question (and my main interest) is:
has perl such a construct available?
.
Marc Espie
bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>I don't think I've *ever* seen a use of operator
>overleading in C++ (which I was exposed to for a
>good while) that made the code clearer or better.
You've probably not been exposed to sparse matrices or expression
templates, two areas where overloading [] may lead to clearer code...
Michael Carman
>
> is there a similar module to overload the classes of build in types
> (like array), something like:
>
> '@' => 'My::Array',
> '%' => 'My::Hash';
> # etc
> ...
You can't overload sigils but you can use tie() to create your own
implementation of the built in data types.
Run "perldoc perltie" for more info.
-mjc
Ilias Lazaridis
this was mentioned in the other thread, too.
But it does not seem to be the construct I am searching for (I would
need a one-liner per module to activate the change, e.g. something
like "use oveloadarray".
The most important use case would be to enable array pointer creation
my $data = []; # assigns an "My::Array" pointer
my $datah = {}; # assigns an "My::Hash" pointer
The direct "sigil overload" has 2nd priority:
my @data; # isa "My::Array"
.
Michael Carman
> On Jun 23, 5:13 pm, Michael Carman wrote:
>> On 6/22/2007 3:09 AM, Ilias Lazaridis wrote:
>>
>>> is there a similar module to overload the classes of build in types
>>
>> implementation of the built in data types.
>
> need a one-liner per module to activate the change, e.g. something
> like "use oveloadarray".
Overloading works because Perl knows what class a variable has been blessed
into. It can interpret operations on that variable based on the class. The $@%
sigals aren't operators. They provide the context in which a variable should be
evaluated. Even if you could overload "@" what would you expect to happen when
you wrote C<$data[0]> or C<$#data>?
> The most important use case would be to enable array pointer creation
>
> my $data = []; # assigns an "My::Array" pointer
my $data = [];
tie @$data, 'My::Array';
Or, if you want to be Lazy:
package My::Array;
sub newref {
my $class = shift;
tie my @array, $class;
return \@array;
}
# tie() implementation ...
package main;
my $data = My::Array->newref();
> The direct "sigil overload" has 2nd priority:
>
> my @data; # isa "My::Array"
tie my @data, 'My::Array';
Is there a reason that won't work for you? If you're really obsessed with this
you could probably write a source filter to do it, but I wouldn't recommend it
as anything other than a learning exercise.
-mjc
Ilias Lazaridis
> On 6/23/2007 9:33 PM, Ilias Lazaridis wrote:
>
> > On Jun 23, 5:13 pm, Michael Carman wrote:
> >> On 6/22/2007 3:09 AM, Ilias Lazaridis wrote:
>
> >>> is there a similar module to overload the classes of build in types
>
> >> You can't overload sigils but you can use tie() to create your own
> >> implementation of the built in data types.
>
> > [This] does not seem to be the construct I am searching for (I would
> > need a one-liner per module to activate the change, e.g. something
> > like "use oveloadarray".
>
> Overloading works because Perl knows what class a variable has been blessed
> > The most important use case would be to enable array pointer creation
>
> > my $data = []; # assigns an "My::Array" pointer
>
> my $data = [];
> tie @$data, 'My::Array';
I am looking for a construct which is importable, e.g.
use UseMyArray;
within "UseMyArray" i do the relevant things, thus "[]" returns an
reference to an "My::Array" instance, instead of a reference to an
perl array.
> Or, if you want to be Lazy:
> package My::Array;
[...] - (obvious OO implementation)
> > The direct "sigil overload" has 2nd priority:
>
> > my @data; # isa "My::Array"
>
> tie my @data, 'My::Array';
same as above.
> Is there a reason that won't work for you? If you're really obsessed with
> this you could probably write a source filter to do it, but I wouldn't
> recommend it as anything other than a learning exercise.
=> probably a "source filter" can solve the problem.
ok, thank you!
I assume the source filter would just replace the "[<construction
data>]" with "My::Array->new(<construction data>).
Thus a perl "source filter" is something like a "custom preprocessor"
or "custom macro".
No problem, I could use such a construct (if no other is available).
Are there any technical(!) negative issues with "source filters" ?
.
Michael Carman
> On Jun 24, 6:14 pm, Michael Carman wrote:
>>
>> you could probably write a source filter
>
>
> I assume the source filter would just replace the "[<construction
> data>]" with "My::Array->new(<construction data>).
>
> Thus a perl "source filter" is something like a "custom preprocessor"
> or "custom macro".
Yep.
> No problem, I could use such a construct (if no other is available).
Nope. We're already invoking the deep magic here.
> Are there any technical(!) negative issues with "source filters" ?
Do you mean aside from confusing the hell out of anyone trying to maintain your
code? By using a source filter you're writing in your own dialect of Perl.
You're using a preprocessor in a language where most other programmers think
that none exists. They will be *completely* unprepared for encountering such
code. It will make maintenance more difficult/costly.
The drawbacks are probably worth it if you're extending the language in order to
create a better way to express your algorithm. For example, the Switch module
adds "switch" and "case" keywords to enable a different paradigm for flow control.
What you're talking about doing isn't extending the language, it's changing it.
Even experienced programmers won't expect "$x = []" to do anything other than
assign a standard anonymous array reference to $x. Source filters like that make
an amusing exercise (for an extreme example see Lingua::Romana::Perligata) but I
don't recommend using them in production code.
-mjc
Ilias Lazaridis
> On 6/24/2007 9:41 PM, Ilias Lazaridis wrote:
>
> > On Jun 24, 6:14 pm, Michael Carman wrote:
>
> >> you could probably write a source filter
>
> > ok, thank you!
>
> > I assume the source filter would just replace the "[<construction
> > data>]" with "My::Array->new(<construction data>).
>
> > Thus a perl "source filter" is something like a "custom preprocessor"
> > or "custom macro".
>
> Yep.
ok
> > No problem, I could use such a construct (if no other is available).
>
> Nope. We're already invoking the deep magic here.
ok
> > Are there any technical(!) negative issues with "source filters" ?
>
> Do you mean aside from confusing the hell out of anyone trying to maintain your
[...] - (elaboration on organizational matters)
I understand that there are no technical issues.
.