Well, you know what they say: one person's bug is another's feature request.

I understand your point.

On Fri, Oct 7, 2016 at 10:54 PM, Chris Marshall <devel.chm...@gmail.com> 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 <marshal...@users.sf.net>
>> 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
>> pdl-devel@lists.sourceforge.net
>> 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
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel

Reply via email to