bugGNU Octave - Bugs: bug #55768, display of classdef object should...

 
 

bug #55768: display of classdef object should not show private or protected properties

Submitter:  Rik <rik5>
Submitted:  Fri 22 Feb 2019 11:34:16 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 04 Jan 2020 04:29:25 AM UTC, comment #11: 

Marking as Fixed and closing report.

Rik <rik5>
Group administrator
Fri 20 Sep 2019 10:55:39 PM UTC, comment #10: 

@jwe: Did you mean to leave this bug open?  The case that prompted the bug report now works.

Rik <rik5>
Group administrator
Sat 15 Jun 2019 07:20:00 PM UTC, comment #9: 

I mean to give special treatment to the identifiers true or false in expressions like


properties (ATTRIBUTE = true)  %% or false


not to generally disallow redefining the true and false functions.

So I guess the test would be whether class definitions with these kinds of attribute lists still work properly if you do have true/false function definitions that shadow the built-in functions.

Also, does Matlab allow things like True or TRUE in attribute lists?  If so, then we need special treatment there anyway.

John W. Eaton <jwe>
Group administrator
Sat 15 Jun 2019 05:36:40 PM UTC, comment #8: 

I just checked with Matlab and the following statement is evaluated correctly in the sense that it creates a new 1x2 variable "true".


true = [pi, 1]


Clearing the variable returns "true" to being a function.  So, no need to change Octave's behavior for Matlab compatibility.

I can also verify that there are no longer obtuse errors and that the test files in this bug report work.

Marking as fixed and closing report.


Rik <rik5>
Group administrator
Sat 15 Jun 2019 04:16:10 PM UTC, comment #7: 

I tracked this down to the evaluation of the expression happening in the current stack frame (top level in this case) and that doesn't correspond to the scope that is used when parsing the classdef object.  So the lookup of the identifier 'true' could pick up some random value from the current frame.  In my case, it was picking up the value of 'ans'.

I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/946c6f117091

As yet another issue, we could still intercept identifiers with names "true" and "false" to avoid the possibility that someone has overloaded those functions globally.  OTOH, if someone does that, then many other things will also break, not just attribute values.

John W. Eaton <jwe>
Group administrator
Sat 15 Jun 2019 04:05:34 AM UTC, comment #6: 

OK, well, that's definitely an unexpected result.  I'll take a look at it.


John W. Eaton <jwe>
Group administrator
Sat 15 Jun 2019 03:42:31 AM UTC, comment #5: 

I am at cset 792fe198c105.  Try adding this line to the local .octaverc file


pkg prefix ~/.octavepkg ~/.octavepkg ;


and then re-test with testprop2.m.

Commenting out the line makes the error go away for me.

Rik <rik5>
Group administrator
Sat 15 Jun 2019 02:34:49 AM UTC, comment #4: 

Rik, which changesets?  With 792fe198c105 tip @ the testprop2 example works for me.

John W. Eaton <jwe>
Group administrator
Fri 14 Jun 2019 10:34:27 PM UTC, comment #3: 

The changesets work on the original example, but fail with a second example that uses Access=private.  The example class is attached as testprop2.m.  Running it gives


octave:1> x = testprop2
x =

  testprop2 object with properties:

error: octave_base_value::bool_value(): wrong type argument 'sq_string'





(file #47100)

Rik <rik5>
Group administrator
Fri 14 Jun 2019 08:40:36 PM UTC, comment #2: 

I didn't realize that there was a separate bug report for this issue.  I checked in the following changes for this problem and referenced bug #56766 in the commit message.

http://hg.savannah.gnu.org/hgweb/octave/rev/42efd1e986c7
http://hg.savannah.gnu.org/hgweb/octave/rev/792fe198c105

Please see the comments for bug #56766 for additional info.

John W. Eaton <jwe>
Group administrator
Fri 14 Jun 2019 12:24:47 PM UTC, comment #1: 

Hi - with the fix I suggested in bug #55766, the output is now:


octave:2> x = testprop
x =

  testprop object with properties:

      protectedtestprop: [1x1 double]
              testprop0: [1x1 double]


I will look more carefully at the handling of protected properties.

ImadES <ies>
Fri 22 Feb 2019 11:34:16 PM UTC, original submission:  

When displaying a classdef object, all properties are printed including Hidden and Protected properties.  This is not what Matlab does, nor is it what the properties() function does which is also confusing.

Consider the following classdef file in testprop.m (also attached):


classdef testprop

        properties
                testprop = 0;
        end

        properties (Access = protected)
                protectedtestprop = 0;
        end

        properties (Hidden = true)
                hiddentestprop = 0;
        end

end


Code to reproduce.


octave:1> x = testprop
x =

testprop object with properties:

     hiddentestprop: [1x1 double]
  protectedtestprop: [1x1 double]
           testprop: [1x1 double]

octave:2> properties (x)
properties for class testprop:

  hiddentestprop
  testprop


The fact that the properties() function shows hidden properties was separately reported at bug #55766.

In terms of architecture, the disp() function for class objects should probably not implement it's own logic.  Instead it should probably call to the underlying function that implements properties() so that it stays in sync with fixes there and there is no code duplication.

Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #47100:  testprop2.m added by rik5 (244B - text/x-matlab)
file #46336:  testprop.m added by rik5 (177B - text/x-matlab)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ies (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-04 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-06-15 jwe StatusFixed Ready For Test
        Open/ClosedClosed Open
    2019-06-15 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-06-15 jwe StatusIn Progress Ready For Test
    2019-06-14 rik5 Attached File- Added testprop2.m, #47100
        StatusReady For Test In Progress
    2019-06-14 jwe StatusNone Ready For Test
    2019-02-22 rik5 Attached File- Added testprop.m, #46336

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code