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


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

Submitted by:  Rik <rik5>
Submitted on:  Fri 22 Feb 2019 11:34:16 PM UTC  
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Ready For Test Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

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>
Project 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>
Project 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>
Project 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:


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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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.


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

John W. Eaton <jwe>
Project 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

                testprop = 0;

        properties (Access = protected)
                protectedtestprop = 0;

        properties (Hidden = true)
                hiddentestprop = 0;


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:


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>
Project Administrator


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

Attach Files:

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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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.5