This conversation was written before the Ruby API documentation was redeployed using YARD, so some of the issues discussed are no longer present in the new interface.
Actually, they are themselves defined as a class (having their own unique functionality) first.
More precisely, they are subclasses of
Their Ruby API docpages clearly state their "parent" class as
Go to the docpage for
Drawingelement, and it's "parent" is given as
Entity, and it's "parent" is given as
Then within the Ruby Console, execute:
The term "parent" is not a Ruby term, and we have asked in the past to have it changed to "superclass". But the engine to generate those old pages is not so flexible it seems. But, it's not so wrong as the first superclass in the inheritance chain, (called it's "ancestors") could logically be referred to as "the direct parent class".
While there is an
ancestors() method to return the array of all a class' ancestor superclasses, there is no dedicated core Ruby
The API however, uses a
parent() method to denote ownership of a drawingelement within the entities collection of another DOM object. (ie, the model itself, or some group or component.)
This tends to cause confusion between "model DOM ownership" and the programming language class inheritance chain. They are two separate things.
Let me stress this. The Document database object tree (ie, the DOM, the exact layout of which is proprietary,) is not the same as the Ruby API class hierarchy (which mimics the underlying C++ classes.) Many newbs confound the two.
The latter is organized for namespace encapsulation to avoid code clashing, and functionality inheritance.
The former (the DOM) is organized to store and transport the model data as a file.
I am not sure what you mean by "zero mention of
... and then: "include an proper object hierarchy in the Ruby docs"
Just FYI, the API documentation's left-column navigation tree is not ordered in any object hierarchy (be it Ruby or DOM.) It is just loosely categorical. And there are misplaced links. Ie, some collection type classes are not beneath the "Collections" category, etc.
This above is no longer valid. In the new YARD interface, the left column navigation pane lists classes by their encapsulating namespace.(There are no longer categorical lists.)
The object hierarchy diagram link was removed because it is old, and some new classes and modules are not on it.
Saving a copy locally might be a good idea. (It was drawn by one of the developers, Roger [RLC] and first posted in the old Google Groups forum.)
(The online diagram link is broken.)
Hey! That is simply MY way of trying to explain a concept. It is not a "rule".
Yes, curve/arcurve information is saved with the model.
Because it and it's subclass
ArcCurve are "virtual" geometry helper classes. They are actually made up of
Edge segments. (In a way they are sort of like Groups, special kinds of components "under the hood.") And I am not saying I like that either. Importers and Exporters often have to read their geometric information and recreate real arcs and circles in the target format.
The simplest explanation why
Curve was not made a subclass of
Drawingelement, is because they did not want the
ArcCurve) classes to inherit the methods of
Sure. I can. The docs got hardly no "love" at all during the Google years. They are slowly getting better.
Also the documentation generators produce a vastly different style of documentation between the C APIs and the Ruby API. (I find the doxygen C docs to be a lot more cumbersome to navigate.)