octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #40064] Legend "interpreter" property not work


From: Glenn Golden
Subject: [Octave-bug-tracker] [bug #40064] Legend "interpreter" property not working correctly
Date: Sun, 01 Jun 2014 22:49:08 +0000
User-agent: Opera/9.80 (X11; Linux i686) Presto/2.12.388 Version/12.16

Follow-up Comment #36, bug #40064 (project octave):

Mike,

Thanks, your responses do indeed help to understand better. 

Unfortunately time is running out this weekend and won't be able to write up
the detailed discussion that I mentioned, but will do so at next opportunity,
probably next weekend or so.  As mentioned, I do think there's a higher-level
importance to this issue of graphical property inheritance that is missing
from the detailed discussion so far of this specific case about the
Interpreter property.

But let me briefly address here one point from your previous two posts.  Maybe
this will also give you an idea of where I'm going with this and why I'm being
such a fussbudget about it.

In Comment #33, you refer to the Matlab legend doc [1], specifically the
bullet list of six properties: Location, Orientation, EdgeColor, TextColor,
Interpreter, String.  In #35, you say that "... a legend is, by Matlab's
definition, an axes object that inherits some of its properties from axes, but
explicitly not the Interpreter property."

The above statements seem to lie at the core of debate on this particular
property. Here's my take on it:

Unfortunately, the bullet list of "exceptions" in [1] is described in a very
confusing way, as a set of properties which are "not shared" with Axes, and
which you then interpreted as meaning "not inherited".  But this doc wording
is very misleading and fails to make a key point: All of those bulleted
"exceptional" properties are properties which Matlab's Axes object doesn't
even have [2], so naturally they're not available for "sharing", or
"inheritance", or in any other way that has anything to do with mutuality
between the two objects.  There isn't any.

Those six properties are simply independent superset properties of a Legend,
which, in Matlab, have no relation whatsoever to its parent Axes.  So drawing
the readers' attention to them in a way which implies that they "could have
been" shared/inherited, but aren't is totally confusing. What they really
meant to say is something like "a legend object also has the following
additional properties beyond those inherited from the parent Axes."

I'm pretty sure that the actual state of affairs in Matlab's Legend object
(and even more generally) is that it does in fact inherit _all_ properties
from its parent Axes object.  Quite a few of those properties are entirely
irrelevant for a Legend (for example all the 'Camera' properties, and many
others) but I believe that all those that are relevant to rendering a Legend
are inherited as-is.

Unfortunately, I can't verify this because I no longer have access to a recent
version of Matlab. But that's my recollection from a few years back when I was
actively using both M and O, and constantly fighting graphical property
inheritance/defaulting issues of this type in order to get complex plots with
complex legends to render identically on both systems. This interpretation is
also supported by the following statement, a few paragraphs earlier in [1]:


    "Legends inherit the properties of axes, although not all of them are
relevant to legend objects."


In other words, Mathworks seems to take the straightforward and ordinary view
that _every_ property of a parent object that is applicable to its subclassed
child is inherited. [3]

So how does this affect the point which you made regarding O/M compatibility? 
Your point was that since Matlab doesn't inherit Interpreter from its parent,
then even though an Octave Axes has an Interpreter property, it should
nevertheless not be inherited by Legend since Matlab's doc explicitly says
that that property isn't "shared" with its parent Axes.  No argument that it
isn't shared/inherited in Matlab -- it doesn't even exist in Matlab's Axes to
be shared or inherited -- but I disagree with your conclusion because it only
tells half the compatibility story.

It seems to me that the other half is this: An Octave Axes _does_ have an
interpreter property, and an Octave Legend -- analogous to a Matlab Legend --
is also documented as being an Axes object, with no mention of inheritance
exceptions (at least in the 3.8.1 doc).  Therefore, one can claim that to be
consistent with Matlab's inheritance model (or simply basic "academic"
inheritance consistency) an Octave Legend _should_ inherit its interpreter
property (and hence it's associated default as well) from the parent Axes.

No argument at all that changing Octave to behave in this way -- inheriting
Interpreter -- would introduce a behavioral incompatibility with Matlab, it
obviously would. But it's also true that not inheriting it simply substitutes
one form of incompatibility for another subtler one.

I would like to try to make the larger case (elsewhere, not here/now) that the
introduction of inheritance inconsistencies _within_ Octave is potentially a
(much) worse side effect than the benefit of present-day script behavioral
compatibility. Especially given the pragmatic fact that as developers, you'll
probably never be able to achieve the latter; and even more discouraging, in
the final analysis, Mathworks has and always will have the ball in determining
how Matlab properties work, and can change things at any time.  So seeking a
very high level of present-day behavioral compatibility is inherently
threading a moving needle, and with the associated frustrations.  And I
suspect that it comes at a significant development resource cost in farting
around with lots of tiny little code details that perhaps are not worth the
trouble and time.

Anyway....  Having already rambled about 5x longer than I intended here, I'll
now STFU.  But that's the essence of where I'm going with this issue in the
larger view.  I'm not trying to be a smartass about it or even imply that the
way it's presently implemented is "wrong", only that it seems worth debating
and opening up the broader question of graphical property O/M compatibility
vs. side effects in general, rather than just dealing with this particular
property in this particular case.

Regards,

Glenn

[1] http://www.mathworks.com/help/matlab/ref/legend.html

[2] http://www.mathworks.com/help/matlab/ref/axes_props.html

[3] http://www.mathworks.com/help/matlab/matlab_oop/defining-properties.html:

     "When you derive one class from another class, the derived (subclass)
class inherits all the properties of the superclass. In general, subclasses
define only properties that are unique to that particular class."



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?40064>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]