bugGNU Octave - Bugs: bug #53084, CamelCase graphic property names...

 
 

bug #53084: CamelCase graphic property names for Matlab Compatibility

Submitter:  Andreas Stahel <sha1>
Submitted:  Wed 07 Feb 2018 09:01:36 AM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Confirmed Assigned to:  None
Originator Name:  Andreas Stahel Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 09 Feb 2018 10:58:09 PM UTC, comment #10: 

Maybe revive the "BrainDead" option? and add a dictionary to be able to switch between IMO more logical Octave convention and MathWorks CamelCase ideology?
It could be worse, AFAIK Java also uses CamelCase except for the very first letter of an iDentiFier.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 09 Feb 2018 07:05:13 PM UTC, comment #9: 

Half (if that) seriously:

Similar to the way gmail ignores some extra characters like "." in email addresses, we could ignore a separator character in property names.  Then you could write


set (groot, 'default_line_linewidth', 1)


John W. Eaton <jwe>
Group administrator
Fri 09 Feb 2018 05:59:53 PM UTC, comment #8: 

Is there really no hope?  Sad!

More seriously, can we not be at least a little better than Matlab?

In the predicate tests the underscore has been useful in denoting things which are Octave specific.  Hence, 'isscalar' is jammed together because the functionality is also available in Matlab under that name.  But, 'is_sq_string' uses underscores to indicate that this is an Octave-specific function.

Also, I have been wanting to redo the graphics properties in the documentation to not have quotes around them, but just use @code.  One of the things I came across was how to logically handle CamelCase within graphic properties.

If things were logical, the CamelCase would occur where there was a break in the variable.  Of course, that is not how Matlab did it.  They chose to break wherever two English words meet.  Hence there is the single graphics property "LineWidth".  It becomes an issue when you start trying to set defaults.  For example:


set (groot, 'DefaultLineLineWidth', 1)


I would prefer to write


set (groot, 'DefaultLineLinewidth', 1)


where it is clear that there are three objects being combined: 1) "Default" to set a default property, 2) "Line" to specify an object type, and 3) "Linewidth" to specify the name of a property.

This will always work since we allow any casing form for the set operation, but will it be more or less confusing because I am not using the form "LineWidth" which is elsewhere in the documentation?


Rik <rik5>
Group administrator
Fri 09 Feb 2018 05:32:16 PM UTC, comment #7: 

I guess there's no hope for the world.

I will begin immediately to convert all of Octave to use CamelCaseVariableNames instead of lower_case_words_separated_by_underscores because that appears to be the way of the future.

John W. Eaton <jwe>
Group administrator
Fri 09 Feb 2018 05:19:35 PM UTC, comment #6: 

Converting Octave to use CamelCase was the obvious solution, but I refrained from mentioning it since I know your dislike of it.


Rik <rik5>
Group administrator
Fri 09 Feb 2018 05:09:10 PM UTC, comment #5: 

OK, thanks.

What would break if we just changed our property names to be CamelCased?  Don't our set and get functions already accept "CamelCased" property names by converting them to lower case?  So we just need to preserve that, but also fix them to find the CamelCased (internal) property names.  Or am I missing something?  Why do we need a two-step transition here?

Ugh, I hate CamelCase, but I guess we are going to have to submit to the will of the CamelCasers.

WTF do people like the CamelCasing so much?

John W. Eaton <jwe>
Group administrator
Fri 09 Feb 2018 04:54:31 PM UTC, comment #4: 

The following is valid in ML, not in Octave:


hf = figure ();
fprops = get (hf);
set (hf, 'outerposition', fprops.OuterPosition * 1.1)


The fields in the structure returned by "get" should be CamelCased. Since this can't be done automatically from lowercase internal property names, we need to store the CamelCase version (and still accept lowercased version as second argument to get/set).

Pantxo Diribarne <pantxo>
Group Member
Fri 09 Feb 2018 04:35:28 PM UTC, comment #3: 

Can you provide a simple example that shows a compatibility problem given Octave's current behavior?

John W. Eaton <jwe>
Group administrator
Fri 09 Feb 2018 04:13:07 PM UTC, comment #2: 

Agree with Pantxo in comment #1.  This is part of a much larger issue which is implementing compatibility for HG2.

Rik <rik5>
Group administrator
Fri 09 Feb 2018 09:51:39 AM UTC, comment #1: 

Yes, there is indeed a compatibility issue between Octave and ML, but changing property names would cause an Octave backward compatibility issue.

A workable approach could be to capitalize property names in the source code (this will be necessary in the future, to support hg2 system) and let "get" return capitalized or lowercase properties depending on a root property, e.g. "lowercase_properties". The latter would be "on" during a short period of time (one version), then "off" (one version), then removed to favor uppercase properties in Octave codes.

Pantxo Diribarne <pantxo>
Group Member
Wed 07 Feb 2018 09:01:36 AM UTC, original submission:  

fig = get(gcf)
returns property names with capital letters in ML, but without
capitals in Octave
e.g.
fig.position  in Octave
fig.Position  in ML

This causes compatibilty problems when using those properties.

Andreas Stahel <sha1>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by sha1 (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-09 rik5 Summarycapitalized property names in get(gcf) CamelCase graphic property names for Matlab Compatibility
    2018-02-09 pantxo StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code