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.
[quote=“tickle, post:9, topic:25592”]
I was aware that ComponentInstance/Definition were of the Entity class, but not of DrawingElement.
The documentation suggest that the lower level entities (faces, edges etc) are DrawingElements, with zero mention of ComponentInstance/Definition.[/quote]
Actually, they are themselves defined as a class (having their own unique functionality) first.
More precisely, they are subclasses of Drawingelement
.
Their Ruby API docpages clearly state their “parent” class as Drawingelement
.
Go to the docpage for Drawingelement
, and it’s “parent” is given as Entity
, and it’s “parent” is given as Object
.
Then within the Ruby Console, execute: Sketchup::Face.ancestors
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 parent()
method.
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 ComponentInstance
/Definition
” ?
… 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.)
[details=(The online diagram link is broken.)]
[/details]
http://www.sketchup.com/intl/en/developer/docs/diagram 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 Curve
(and ArcCurve
) classes to inherit the methods of Drawingelement
.
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.)