API Docs Comments

[Chris Fullmer]

Its great Jim! I've already done the entire constructionpoint class .

[thomthom]

@chris fullmer said:

Its great Jim! I've already done the entire constructionpoint class .

@unknownuser said:

point1 = Geom::Point3d.new (10,0,0)

Spaces between method name and parentheses yields warnings:
(eval):894: warning: don't put space before argument parentheses

[thomthom]

Would be nice if the classes listed what class their inherit from.

[Jim]

@thomthom said:

Would be nice if the classes listed what class their inherit from.

Well fix it!

[Chris Fullmer]

Eaxctly!

I copied that example from the API and I didn't notice the extra space there.

Chris

[thomthom]

I added Parent reference.

And condensed the steps to create the sample CPoint in the example. (I don't see the need for all the small steps that the Google API has. At least not when they are just there to create sample objects to later demonstrate the method.)

Also added a comment of the return value in the example. Something I have been missing in the Google API docs.

Agree or disagree?

[thomthom]

Jim, I just noticed the label system. You had labelled the classes inherited from Drawingelement. Nice system of organising.

[Jim]

@thomthom said:

im, I just noticed the label system. You had labelled the classes inherited from Drawingelement. Nice system of organising.

Yeah, it worked out nicely. I can't say I planned it that way, though!

[thomthom]

I think we can do the same for Entity, Tool, and Observers. Though observers are not inherent from an Observer class, could be nice to have them labelled like that?

[Dan Rathbun]

@thomthom said:

... Though observers are not inherent from an Observer class, could be nice to have them labelled like that?

One of my peeves with the SU API. There should be a Sketchup::Observer common class, which could have been a subclass of the Ruby base class Observer.

[Jim]

Is there a name for the classes that don't really exist other than to define an interface?

For example, there is no actual Tool base class in Sketchup. It's just a convention. An instance of any object can be a "Tool" if it responds_to certain instance_methods.

[Dan Rathbun]

@dan rathbun said:

I called it a "protoclass" (but not sure I used the correct term.)

@unknownuser said:

(http://dictionary.reference.com/browse/proto )":2sb0s94w]proto- 
a combining form meaning “first,” “foremost,” “earliest form of,” used in the formation of compound words ...

[Dan Rathbun]

@jim said:

For example, there is no actual Tool base class in Sketchup. It's just a convention. An instance of any object can be a "Tool" if it responds_to certain instance_methods.

Reference, a topic at GoogleGroups:

@unknownuser said:

(http://groups.google.com/group/sketchupruby/tree/browse_frm/thread/6e6ead6cade3807a/440e3c753370ab23?rnum )":c5ik998j]
@unknownuser said:

(http://groups.google.com/group/sketchupruby/tree/browse_frm/thread/6e6ead6cade3807a/f1c8fdd8b6d98c72?rnum )":c5ik998j]2. I am sort of puzzed about what makes a tool. Is it the fact that it uses "Tool" methods?

Yes it is strange. There is not a Sketchup::Tool protoclass actually defined (but there could be, and might be argued, should be.)

So actually what makes a tool is that Sketchup treats an object as a tool if you call Sketchup.select_tool( object ); as up to that point Ruby and Skecthup would not know what it is supposed to be.

So then, SU assumes that it 'could' have any of the standard tool callback methods. I think .activate would be considered as a required method. While the tool is active, Sketchup sends information to the object by calling the method names defined in the API.

I called it a "protoclass" (but not sure I used the correct term.) IF there was a Sketchup::Tool class (and there really should be to be 'proper' OOP Ruby,) then it would called the superclass of the custom Tool subclass(es) that we write.

It would NOT be a baseclass, because they are defined at the toplevel, and generic to the entire Ruby world, not just Sketchup.

[Dan Rathbun]

So...

@jim said:

Is there a name for the classes that don't really exist other than to define an interface?

Would they then be called protoless classes ??

[Dan Rathbun]

@dan rathbun said:

So...

@jim said:

Is there a name for the classes that don't really exist other than to define an interface?

Would they then be called protoless classes ??

Looking through Dictionary.com (Thesaurus tab) for 'protoless' synonyms:

• Concocted
• Contrived
• Ad lib

Or perhaps:

• demiclass

[Jim]

This is an html page of the SketchUp API classes. Save it as a .html file, and then bookmark it in Firefox. Edit the bookmark to open in the Sidebar. Instant API sidebar.

[Chris Fullmer]

Jim, I think you forgot the link or something

[Jim]

Hmmm, first time that's ever happened...

The forum doesn't like HTML, so I uploaded it encoded.

• Open it in Notepad++,
• Select all
• Plugins > MIME Tools > Base64 decode
• Save as api_sidebar.html

(same way to decode those non-rbs encrypted scripts, btw.)

---

api_sidebar.txt

[Dan Rathbun]

ISSUE: the improper use of "Parent"

Speaking specifically on: ConstructionPoint

Familial terms: ie: parent and child are reserved for the instance object heirarchy, such the HTML Document Object Model, and in our case the Sketchup SKP document heirarchy.

Example: the model object has children that can be Component, which can have children Groups, which may have children Edges and Faces, and so on.
A Face instance inside a Group has THAT Group instance as it's Parent, but Group is NOT the superclass of Face.

You will notice that in the SU API all .parent methods refer to the specific instance object's relationship within the document heirarchy.

The correct terms are superclass, subclass, and class; all always LOWERCASE because Class (UPPERCASE,) is a specific class Identifier.

[Jim]

Thanks Dan,

The ConstructionPoint page looks good.

I am all for using the right terminology - i just don't know what that is all the time.

How about ancestors and descendants?