Core ruby policies

[cjthompson]

This is probably a pretty stupid question, but do you know if there are any policies in sketchup against using core ruby code?
The reason I'm asking is because of .methods. This allows you to see all the public methods of an object.

I noticed some undocumented methods, and was wondering if they were purposefully left undocumented, or just overlooked.

[Jim]

It seems like a good idea to stay away from undocumented API methods. They could change at anytime and without notice.

The SKSocket class is a prime example. I asked the SketchUp engineers about it and they told me the same thing I just said.

What did you find?

[NewOne]

@cjthompson said:

This is probably a pretty stupid question, but do you know if there are any policies in sketchup against using core ruby code?
The reason I'm asking is because of .methods. This allows you to see all the public methods of an object.

I noticed some undocumented methods, and was wondering if they were purposefully left undocumented, or just overlooked.

Well, tell us about them!

[cjthompson]

@jim said:

It seems like a good idea to stay away from undocumented API methods. They could change at anytime and without notice.

would you suggest adding them into http://forums.sketchucation.com/viewtopic.php?f=180&t=17047 with a warning/notice? I personally don't have any need for them, but they may be useful for others.

@newone said:

Well, tell us about them!

The most useful ones I could find were in Sketchup::Transformation: rotx, roty and rotz which will give you rotation in degrees about an axis, and xscale, yscale and zscale which give you the scaling factor.

[Jim]

Oh, don't forget some of those may not be "undocumented", but rather could have been added by various plugins.

[cjthompson]

ok. just tested with a clean plugins folder and the ones I listed are still there.

[Jim]

You'd need to eliminate the Tools folder also for a thorough test. Dynamic Components, Sandbox, and other things live there.

And not all the methods returned by .methods are callable on the object even though they appear in the output. I would think .instance_methods would be of the most interest for objects.

module Geom
  class Transformation
    def transmogrify; end
  end
end

Geom;;Transformation.instance_methods(false)
["roty", "zscale", "xaxis", "rotx", "yscale", "origin", "invert!", "zaxis", "xscale", "inverse", "identity?", "set!", "rotz", "transmogrify", "clone", "*", "yaxis", "to_a"]

and .singleton_methods for modules

Geom.singleton_methods(false)
["intersect_plane_plane", "linear_combination", "intersect_line_plane", "point_in_polygon_2D", "intersect_line_line", "closest_points", "fit_plane_to_points"]

But again, you can not tell which is a built-in API method and which is not.

[NewOne]

@cjthompson said:

ok. just tested with a clean plugins folder and the ones I listed are still there.

How do you use .methods ? I tried Sketchup.methods and it woeked, but several tries gave me errors.

Sorry. Figured out how

[cjthompson]

I tried getting rid of the tools folder, and you were right, they aren't part of the core API. I'm trying to figure out which file it is from, but that might take a while.

[Chris Fullmer]

There is a good chance they are part of the Dynamic Components. But those are encrypted so it would be hard to read the file.

Chris

[Jim]

And you can't actually count on these inspections to give the right or complete results:

Here's the Materials Observer , for example:

Sketchup;;MaterialsObserver.instance_methods false
["MaterialUndoRedo", "onMaterialRemoveAll", "MaterialSetCurrent", "MaterialChange", "onMaterialAdd", "MaterialRefChange", "MaterialRemove"]

Wrong results, but the documented events do get fired. (at least some.)

[cjthompson]

@chris fullmer said:

There is a good chance they are part of the Dynamic Components.

yeah. they are part of dcutils.rbs