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

 
 

bug #53084: CamelCase graphic property names for Matlab Compatibility

Submitted by:  Andreas Stahel <sha1>
Submitted on:  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

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

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

I would prefer to write

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>
Project 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>
Project 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>
Project 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>
Project Administrator
Fri 09 Feb 2018 04:54:31 PM UTC, comment #4:

The following is valid in ML, not in Octave:

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>
Project 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>
Project 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>
Project 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>
Project 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)
  •  

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