Copying a null PDL implicitly reads data from the null PDL (to copy it), which
is invalid. The behavior is certainly allowed based on that.
That said, I think it would be more consistent and less surprising to either:
- retain nullness across copying and severing.
- throw an error when copying or severing a null PDL.
I think the former is more “perlish”, and therefore I agree with Diab that this
might be an improvement over the current behavior.
> On Oct 7, 2016, at 8:54 PM, Chris Marshall <[email protected]> wrote:
>
> Hi Diab-
>
> I generally prefer have bug tickets be for
> things that are broken while enhancements and
> new features or API changes would be added as
> feature request tickets. That said, I'm not usually
> picky either---except when we're in feature freeze
> for a new release and adding a feature request as
> a bug means I have a new problem to report in the
> Known_Problems file for the release... :-)
>
> The proposed copy behavior would "do what I mean" here which
> seems appropriate---but definitely not clear from the POD.
>
> I think that the special nature of being a placeholder for LHS
> assignment operations should be clarified w.r.t. non-LHS
> operations and behavior. For example, I read the docs as
> stating the Null piddle value is only "possible" on the LHS
> (other use is unspecified and null->copy => Empty seems to
> be a reasonable outcome---I still like the principle of
> least surprise value above...)
>
> Seems a simple change but I don't know enough about
> the threadI and sever operations on Null piddles to
> apply something for the release I'm planning to push
> tomorrow AM.
>
> Cheers,
> Chris
>
>
>
>
>
> On 10/7/2016 17:30, Diab Jerius wrote:
>> [I'm moving discussion of this here at Chris' request and top-posting,
>> which looks like is
>> the default behavior for this list]
>>
>> Executive summary,
>>
>> I expect PDL->null->copy to return a null piddle, it returns an empty one.
>> ]
>>
>> I don't read the docs in the same way. Here's the excerpt from PDL::Core
>>
>> PDLs on the left-hand side of assignment can have the special value
>> "Null". A null PDL has no dim list and no set size; its shape is
>> determined by the computed shape of the expression being assigned to it.
>> Null PDLs contain no values and can only be assigned to. When assigned
>> to (e.g. via the ".=" operator), they cease to be null PDLs.
>>
>> There's nothing here which says that null's are only valid on the LHS,
>> only that they have a special behavior when assigned to. I would like
>> to be able to count on that behavior when a null piddle is copied
>> without having to explicitly check if it is null. For example let's
>> say I have an object which contains one or more piddles and I'd like
>> to clone it, which would involve copying the piddles to the clone. I
>> don't believe the code should care if the source piddle is null or
>> not. I'd rather do this:
>>
>> use Safe::Isa;
>> sub clone {
>> my $self = shift;
>> my %new = %$self;
>> $new{$_} = $self->{$_}->copy for $self->{$_->$_isa( 'PDL' ) };
>> return bless \%new, ref $self;
>> }
>>
>> rather than
>>
>> use Safe::Isa;
>> sub clone {
>> my $self = shift;
>> my %new = %$self;
>> $new{$_} = $self->{$_}->isnull ? PDL->null : $self->{$_}->copy
>> for $self->{$_->$_isa( 'PDL' ) };
>> return bless \%new, ref $self;
>> }
>>
>> It's inconsistent for copy() to return anything other than an exact copy.
>>
>> Could you define what you mean by "inappropriate context"? That might
>> help me understand your argument.
>>
>>
>>
>> On Fri, Oct 7, 2016 at 12:34 PM, Chris Marshall <[email protected]>
>> wrote:
>>> - **Group**: normal --> feature_request
>>> - **Priority**: 5 --> 1
>>> - **Comment**:
>>>
>>> Per the docs a Null piddle is only valid on the LHS of an assignment
>>> statement. Changing this to a feature request since it seems to be more of
>>> a discussion regarding how to treat/use Null piddles in inappropriate
>>> contexts. Croaking might be more appropriate although, ignoring the
>>> specialness of Null piddles and trying to do the right (wrong) thing could
>>> be more friendly. API discussion is needed. Please continue discussion on
>>> the PDL mailing lists.
>>>
>>>
>>>
>>> ---
>>>
>>> ** [bugs:#427] PDL->null->copy returns an empty (not null) piddle**
>>>
>>> **Status:** open
>>> **Group:** feature_request
>>> **Labels:** 2.016
>>> **Created:** Thu Oct 06, 2016 06:31 PM UTC by Diab Jerius
>>> **Last Updated:** Thu Oct 06, 2016 06:31 PM UTC
>>> **Owner:** nobody
>>>
>>>
>>> PDL v. 2.016
>>>
>>> Copying a null piddle returns an empty piddle:
>>>
>>> ~~~
>>> % perl -MPDL -E 'say PDL->null->copy->info'
>>> PDL: Byte D [0]
>>>
>>> % perl -MPDL -E 'say PDL->null->copy->isnull'
>>> 0
>>> ~~~
>>>
>>> I expect it to return another null piddle.
>>>
>>>
>>> ---
>>>
>>> Sent from sourceforge.net because you indicated interest in
>>> <https://sourceforge.net/p/pdl/bugs/427/>
>>>
>>>
>>>
>>> To unsubscribe from further messages, please visit
>>> <https://sourceforge.net/auth/subscriptions/>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> pdl-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> pdl-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
pdl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pdl-devel
