Home > Archive > PERL Miscellaneous > June 2007 > How can I overload the build in array type?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How can I overload the build in array type?
|
|
| Ilias Lazaridis 2007-06-22, 8:04 am |
| perl [http://search.cpan.org/~nwclark/per...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
...
}}}
-
(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)
..
--
http://dev.lazaridis.com/lang/ticket/17
| |
| bugbear 2007-06-22, 8:04 am |
| Ilias Lazaridis wrote:
> perl [http://search.cpan.org/~nwclark/per...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 2007-06-22, 8:04 am |
| On Jun 22, 11:20 am, bugbear <bugbear@trim_papermule.co.uk_trim>
wrote:
> Ilias Lazaridis wrote:
>
>
>
>
>
>
> 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?
..
--
http://dev.lazaridis.com/lang/ticket/17
| |
| Marc Espie 2007-06-23, 10:09 pm |
| In article <467b863b$0$8753$ed2619ec@ptn-nntp-reader02.plus.net>,
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 2007-06-23, 10:09 pm |
| On 6/22/2007 3:09 AM, Ilias Lazaridis wrote:
>
> is there a similar module to overload the classes of build in types
> (like array), something like:
>
> use typeoverload
> '@' => '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 2007-06-23, 10:09 pm |
| On Jun 23, 5:13 pm, Michael Carman <mjcar...@mchsi.com> wrote:
> On 6/22/2007 3:09 AM, Ilias Lazaridis wrote:
>
>
>
>
>
> 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.
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"
..
--
http://dev.lazaridis.com/lang/ticket/17
| |
| Ilias Lazaridis 2007-06-24, 10:03 pm |
| On Jun 24, 6:14 pm, Michael Carman <mjcar...@mchsi.com> wrote:
> On 6/23/2007 9:33 PM, Ilias Lazaridis wrote:
>
>
>
>
>
> Overloading works because Perl knows what class a variable has been blessed
[...] - (other construct)
>
>
> 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)
>
>
> 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" ?
..
--
http://dev.lazaridis.com/lang/ticket/17
| |
| Michael Carman 2007-06-25, 7:10 pm |
| On 6/24/2007 9:41 PM, Ilias Lazaridis wrote:
> On Jun 24, 6:14 pm, Michael Carman wrote:
>
> 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.
> 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 2007-06-26, 8:03 am |
| On Jun 26, 3:07 am, Michael Carman <mjcar...@mchsi.com> wrote:
> On 6/24/2007 9:41 PM, Ilias Lazaridis wrote:
>
>
>
>
>
>
> Yep.
ok
>
> Nope. We're already invoking the deep magic here.
ok
>
> 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.
..
--
http://dev.lazaridis.com/lang/ticket/17
| |
|
|
|
|
|