Nice! I was not aware that Perl allowed calling a method from an unrelated
package (if you take the risk). Thanks!
Regards,
Luis
On Mon, Jan 29, 2024 at 10:19:56PM -0500, David Mertens wrote:
> Hello Luis,
>
> Ever crafty, Perl gives you another way to solve this. You could put your
> functions under another name space and invoke them by explicitly naming the
> package and function. For example, if you have a function "do_it" in
> package MY, you could invoke it as
>
> $pdl->MY::do_it(...args...)
>
> For brevity you would do well to choose a short-named top-level namespace.
> This of course runs the possibility of conflicting with other things, but
> it is very unlikely to conflict with PDL since PDL doesn't put stuff
> outside of its namespace. (Except for PDL::Graphics::Prima, which follows
> the Prima convention of putting certain groupings of constants/functions in
> top-level namespaces to avoid import/export craziness. Of course, if you
> use PDL::Graphics::Prima, you already know about them, and if you don't, it
> doesn't matter.) Here's a complete (non-PDL-specific) working example
> illustrating the basic idea:
>
> --------%<--------
> use strict;
> use warnings;
>
> package foo;
>
> sub new {
> my ($class, %values) = @_;
> return bless \%values, $class;
> }
>
> sub hello {
> my ($self) = @_;
> my $name = $self->{name} // '(no name)';
> print "Hello from $name\n";
> }
>
> package alpha;
>
> sub beta_speak {
> my $self = shift;
> print "Beta speak alpha!\n";
> $self->hello;
> }
>
> package main;
>
> my $thing = foo->new(name => 'elgar');
>
> print "hello() method\n";
> $thing->hello;
> print "alpha::beta_speak\n";
> $thing->alpha::beta_speak;
>
> print "All done!\n";
> -------->%--------
>
> David
>
> On Sun, Jan 28, 2024 at 12:21 PM Luis Mochan <moc...@icf.unam.mx> wrote:
>
> > Thanks!
> >
> > Regards,
> > Luis
> >
> > On Sun, Jan 28, 2024 at 04:25:27PM +0000, Ed . wrote:
> > > Hi Luis,
> > >
> > > This is a long-standing issue in PDL. If your code creates a
> > PDL::somefunction, there is indeed a risk that someone else’s code also
> > makes a PDL::somefunction, and there will be a problem. Using “warnings” in
> > both modules will at least tell you it happened.
> > >
> > > A way to dodge this is to make a subclass of PDL called e.g. PDL::Other
> > that all your code’s objects are in, and instead make
> > PDL::Other::somefunction. You’d create objects with
> > PDL::Other->new(@args_as_normal). This is tested in t/subclass.t and ought
> > to work, including that any operations’ results will also be in that
> > subclass. If you try it and find any surprises, please say so on here! Then
> > I can capture that into t/subclass.t and fix it.
> > >
> > > Best regards,
> > > Ed
> > >
> > > ________________________________
> > > From: Luis Mochan <moc...@icf.unam.mx>
> > > Sent: Sunday, January 28, 2024 2:41:27 PM
> > > To: perldl <pdl-general@lists.sourceforge.net>; perldl <
> > pdl-de...@lists.sourceforge.net>
> > > Subject: [Pdl-devel] naming conventions
> > >
> > > Hi,
> > > It is sometimes convenient to call my own functions that operate on
> > ndarrays
> > > using the object notation: $ndarray->somefunction. A simple way to do
> > > it is to define the function within the PDL name space as in
> > > sub PDL::somefunction($self,...){...}
> > > Is there a better way? Adding functions to a package as a user of that
> > > package is risky as there might be a name collision with internal
> > > functions actually defined within the PDL packages. Is there a naming
> > > convention in PDL to avoid the collision? I vaguely recall there are
> > > some subtleties if one wants to make new classes derived from PDL.
> > > Regards,
> > > Luis
> > >
> > >
> > > --
> > >
> > > o
> > > W. Luis Mochán, | tel:(52)(777)329-1734 /<(*)
> > > Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\
> > > Av. Universidad s/n CP 62210 | (*)/\/
> > \
> > > Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/
> > > GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
> > >
> > >
> > > _______________________________________________
> > > pdl-devel mailing list
> > > pdl-de...@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/pdl-devel
> >
> > --
> >
> > o
> > W. Luis Mochán, | tel:(52)(777)329-1734 /<(*)
> > Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\
> > Av. Universidad s/n CP 62210 | (*)/\/ \
> > Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/
> > GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
> >
> >
> > _______________________________________________
> > pdl-devel mailing list
> > pdl-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/pdl-devel
> >
>
>
> --
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." -- Brian Kernighan
> _______________________________________________
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
--
o
W. Luis Mochán, | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\
Av. Universidad s/n CP 62210 | (*)/\/ \
Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
_______________________________________________
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general
