Extending ComponentInstance Class

fizgig

I want to add a new method to the ComponentInstance class. Not sure if it's possible. Here's the basic idea:

class ComponentInstance
	def yo
		UI.messagebox("Tada!")
	end
end #class ComponentInstance

I then have try to call the "yo" method on a component instance later and it says the method yo is undeclared.

Am I missing something?

Chris Fullmer

Change it to this and it will work:

class Sketchup;;ComponentInstance
   def yo
      UI.messagebox("Tada!")
   end
end #class ComponentInstance

You need to specify that the ComponentInstance class is a subclass of the Sketchup class. (did I get my terminology right?)

Chris

fredo6

@chris fullmer said:

You need to specify that the ComponentInstance class is a subclass of the Sketchup class. (did I get my terminology right?)

Chris

Actually "ComponentInstance is a class of the Sketchup module"

to fizgig
It is not a good practice to subclass a built-in class, whether Ruby or Sketchup. This could generate clashes between scripts and conflicts in names. Just imagine I do the same, and my script is loaded after yours, then it would be my version prevailing, and your script would not work!
The best is that you write a method within your namespace (module or class):


module Mymodule
....
def Mymodule.comp_yo(comp)
   UI.messagebox("Tada!")
end

....
end  #module Mymodule

Fredo

AdamB

@unknownuser said:

It is not a good practice to subclass a built-in class, whether Ruby or Sketchup. This could generate clashes between scripts and conflicts in names. Just imagine I do the same, and my script is loaded after yours, then it would be my version prevailing, and your script would not work!

I'm sure what Fredo meant to say is that its not good practice to overload (or to some degree) extend a built-in class. Its very good practice to derive from / subclass an existing class to create a specialization you may want.

Adam

fizgig

Understand the concerns. On the way home from work I figured out a way to not have to take this approach but it's good to understand what's going on. Thanks!

thomthom

@adamb said:

@unknownuser said:

It is not a good practice to subclass a built-in class, whether Ruby or Sketchup. This could generate clashes between scripts and conflicts in names. Just imagine I do the same, and my script is loaded after yours, then it would be my version prevailing, and your script would not work!

I'm sure what Fredo meant to say is that its not good practice to overload (or to some degree) extend a built-in class. Its very good practice to derive from / subclass an existing class to create a specialization you may want.

Adam

It's the potential that multiple plugin authors might extend a base class and create conflict.

AdamB

Hence my point that extending a class has the potential of conflict. Deriving a new class does not.

thomthom

Ah. Sorry, my bad. Mis-read that.

fredo6

@adamb said:

I'm sure what Fredo meant to say is that its not good practice to overload (or to some degree) extend a built-in class. Its very good practice to derive from / subclass an existing class to create a specialization you may want.

Adam

Thanks Adam, this is exactly what I meant.
Somehow, the best would be that we restrict the possibility of name clashing only at Module level, which implies that all scripts are alway encapsulated within modules, so that it is easier to control.