New API Object Diagram

scottlininger

We're happy to announce a new feature on the Ruby Docs site, an object hierarchy diagram for the core parts of the API. Hopefully this will make it easier for SketchUp programmers to groc how things are related.

Thanks to our QA master, Simone, for putting this together. You can read his blog post here.

remus

Thanks, thats really helped me understand a bit more about how ruby works in SU

Jim

Cool - a bit more comprehensive than mine.

Something I'm curious about - why is a ComponentDefinition a DrawingElement? It's clear why an ComponentInstance is_a DrawingElement, but not sure about why the Definition needs to be.

scottlininger

@jim said:

Something I'm curious about - why is a ComponentDefinition a DrawingElement? It's clear why an ComponentInstance is_a DrawingElement, but not sure about why the Definition needs to be.

The only reason that I'm aware of is so it inherits .bounds from Drawingelement. That's really the only Drawingelement method that makes sense in a definition context.

Other than that? "Historical reasons."

todd burch

Thanks Simone!!!

Matt666

Great
Just two things, correct me if I'm wrong:

Groups also have component definitions
Curves and ArcCruves are edges

RickW

@matt666 said:

Great
Just two things, correct me if I'm wrong:

Groups also have component definitions

Curves and ArcCruves are edges

Groups are found in the ComponentDefinitions, but you can't (necessarily/natively) call group.definition. However, copies of a group will act like instances until they are made unique (meaning that if you change one via ruby, all will change). You can make them unique by manually editing them or by calling group.make_unique (ruby will yell at you that it's a deprecated method, but it's absolutely necessary until this bug is fixed).

Curves and ArcCurves are not edges. They are comprised of edges, but a curve is not an edge. That's why you have curve.edges (to get the edges that comprise the curve) and edge.curve (to get the curve of which that edge is a part).

Hope that clarifies things...

Matt666

Ok, thank you Rick!

Jim

The new API Graph helps to clarify.

Curves and ArcCurves are not Drawingelements as Edges are. That means they are really defined by their methods (and properties) rather than the type of object they appear to be on the screen.

So an ArcCurve IS_A Curve IS_A Entity - so you can't work with them the same way you can with edges (or Drawingelements) because they do not share the same methods. You need to go back to the Entity class to find methods that are shared between Drawingelements and Curves/ArcCurves.

There is an idea in the Ruby community called "duck typing". If something (object) walks like a duck and quacks like a duck, then it IS a duck. The practical result is that instead of checking what type (or class) an object is, you check the object's properties.

For a simple example, if we want to collect all the Vertices in a selection most of us would do the following:


verts = []
Sketchup.active_model.selection.each { |e|
  if( (e.is_a? Sketchup;;Face) or (e.is_a? Sketchup;;Edge) )
    verts.concat(e.vertices)
  end
}

Duck typing says it's better to write it this way:


verts = []
Sketchup.active_model.selection.each { |e|
  if( e.respond_to?("vertices") )
    verts.concat(e.vertices)
  end
}

We don't really care about what type of object 'e' is, only that it has vertices.

Sorry. I'm not sure how I got into that last topic, but there it is.

Chris Fullmer

Thats a great example there Jim, and it makes much more sense. Its easy to write it the way you did in the first example because there are only edges and faces that that have vertices. But what if there were 30 different types of objects that did? That would be hard to be all inclusive. So I like the idea that there is no need to specifiy each class separately, since its really not the edge or face we care about. Its if the "e" in question has vertices attached. Interesting. I'll be thinking baout that as I keep working....

Chris

thomthom