Adding methods.

mptak

I presume that by adding methods to the Sketchup::ComponentInstance class I am breaking
all the rules(too much Sketchy Physics for me I guess). With this small code snippet can someone advise a more correct way. In this example I am just doing a rotation of 1/24th of a revolution about each axis

require 'sketchup.rb'

class Sketchup;;ComponentInstance
    ##adding methods which allow for 15 degree (PI/12) incremental rotations to components
		
	def check
		#only updates position when this is called as opposed to the component transformation
		@gname = self.name
		@xpos=self.transformation.to_a[-4]
		@ypos=self.transformation.to_a[-3]
		@zpos=self.transformation.to_a[-2]
		@pos=self.transformation.to_a[12..14]
		@zaxis=self.transformation.to_a[8..10]
		@xaxis=self.transformation.to_a[0..2]
		@yaxis=self.transformation.to_a[4..6]
		puts "updated the position"
	end
		 
	def rotx
		self.check
		t=Geom;;Transformation.new(@pos,@xaxis,(Math;;PI)/12.0)
		self.transform!(t)
	end
			 
	def roty
		self.check
		t=Geom;;Transformation.new(@pos,@yaxis,(Math;;PI)/12.0)
		self.transform!(t)
	end
		 
	def rotz
		self.check
		t=Geom;;Transformation.new(@pos,@zaxis,(Math;;PI)/12.0)
		self.transform!(t)
	end
end

TIG

Usage: pass the the x/y/z methods an instance and an angel
MPTAK::Rotate.x(instance, 15)***

module MPTAK
  module MPTAK;;Rotate
    def self.get_trans(inst)
      #@gname = inst.name ### unused ??
      @xpos=inst.transformation.to_a[-4]
      @ypos=inst.transformation.to_a[-3]
      @zpos=inst.transformation.to_a[-2]
      @pos=inst.transformation.origin ### ?
      @zaxis=inst.transformation.to_a[8..10]
      @xaxis=inst.transformation.to_a[0..2]
      @yaxis=inst.transformation.to_a[4..6]
      #puts "updated the position"
   end
   def self.x(inst, a=0)
      return nil unless inst.is_a?(Sketchup;;ComponentInstance)
      self.get_trans(inst)
      t=Geom;;Transformation.new(@pos, @xaxis, a.degrees)
      inst.transform!(t)
   end  
   def self.y(inst, a=0)
      return nil unless inst.is_a?(Sketchup;;ComponentInstance)
      self.get_trans(inst)
      t=Geom;;Transformation.new(@pos, @yaxis, a.degrees)
      inst.transform!(t)
   end
   def self.z(inst, a=0)
      return nil unless inst.is_a?(Sketchup;;ComponentInstance)
      self.get_trans(inst)
      t=Geom;;Transformation.new(@pos, @zaxis, a.degrees)
      inst.transform!(t)
   end
  end
end

***Instead of (Math::PI)/12.0) use a.degrees and you can then pass any angle in degree to the method - like 15
Note how ' inst' is the instance while now ' self' is the method...
I renamed the ' check' method as ' get_trans' as it seems a more logical name ?

mptak

Thanks heaps. I am trying to finally make the leap to thinking in an object oriented way and guess from
your excellent code that there are times when doing so (adding methods to a class) will break the rules and conventions of the sketch-up community. So I am guessing that besides my marginal code, adding methods to core classes is pretty much verbotten (or however you say that in Portuguese.).

In general Ruby (or Python as well) it seems that you use subclasses but this seems problematic. I'll dissect your as always succinct code and see how I can apply its themes to make my ruby creations less hacky.

Dan Rathbun

@mptak said:

In general Ruby (or Python as well) it seems that you use subclasses but this seems problematic.

Only because, currently, the C-side of the API does not know how to handle subclasses. It does not know how to draw them, and it's entities collections are not set up to hold them. Not to mention that the methods for adding entities raise exceptions if you try to use subclasses.

tt_su

@mptak said:

I presume that by adding methods to the Sketchup::ComponentInstance class I am breaking
all the rules

Any plugin that modified the core Ruby and SketchUp classes and modules will not be accepted to the Extension Warehouse. This is because of the risk of clashing with other plugins if they implemented the same modifications. Or even our method if we decided we wanted methods with the same name. (And it's hard to debug when there's like 100 plugins installed on a user's machine.)

Since the SketchUp Ruby API is a shared environment ensure you encapsulate all your code into your own namespace (module). That way you ensure you don't conflict with other extensions.

If you plan to submit to Extension Warehouse I'd recommend that you read up on the guidelines before you start your project so you can save yourself some refactoring. The guidelines are there to ensure no conflict and encourage good practices so they are good to read in any case.
http://extensions.sketchup.com/developer

General guidelines I wrote up a while back:
http://www.thomthom.net/thoughts/2012/01/golden-rules-of-sketchup-plugin-development/

tt_su

@mptak said:

In general Ruby (or Python as well) it seems that you use subclasses but this seems problematic.

Yes, though then it's normally in a server environment where you have more control over the environment where your code is run. In SketchUp the user controls the environment and the developer is the guest - flipping the roles.