Forward compatibility?

[thomthom]

What if we implement missing methods that Google later wants to implement?
What if we fix bugs in a method that Google later fixes.

I'd think that Google's code would run faster than ours, but we'd rather not override that unless we have to.

So for new methods - we could add a little check routing before the method definition that checks for the existence of that method?


Not sure about bug fixing methods. If we do a version check we have to update the methods when a new version comes out whether it fixes the bug or not. If we leave it, we will have to update the methods that's been fixed.


Ideas? Thoughts?

[Dan Rathbun]

thomthom wrote:

"What if we implement missing methods that Google later wants to implement? ... I'd think that Google's code would run faster than ours, but we'd rather not override that unless we have to. ... So for new methods - we could add a little check routing before the method definition that checks for the existence of that method?"

Compiled C would always run faster than interpreted Ruby, I would think.

Code: Select all

# sample override code, assume a 'menu_wizard'
module ::Sketchup

if not defined? Sketchup.menu_wizard
  if Sketchup.version_number <= '7.1.4870'
    def self.menu_wizard
      .. { code goes here } ..
    end
  else # different code for newer version of Sketchup
    def self.menu_wizard
      .. { code goes here } ..
    end
  end
end

end # module


thomthom wrote:

"What if we fix bugs in a method that Google later fixes."
..and..
"Not sure about bug fixing methods. If we do a version check we have to update the methods when a new version comes out whether it fixes the bug or not. If we leave it, we will have to update the methods that's been fixed."

We would always need to check ANY method overrides (or mix-ins) when new versions of Sketchup or the SU ruby API are released. It would be nice if Google gave us a 'heads-up" before hand... we have a Google programmer as a SKX member so perhaps that may happen.

If we override ANY method, in ANY Google SU module... what we are doing is saying "this should be a part of the module in the future, and this override is only temporary until Google actually does add the features in a later release.

Afterall... those modules really "belong" or are "owned" by Google.


Some perfect examples:
NO "Sketchup.unregister_extension" method
Methods to set text on StatusBar, VCB_Label and VCB_Value, but NO methods to GET the actual text (assume the text was set by Sketchup itself, or another plugin,) if I want to do something, such as stuff a value for a Radius into the VCB, when the VCB Label says a certain string, I can't do it easily (I could write a API call sure, but this should have been part of the standard Sketchup module method set.) Yes there is a onToolStateChanged event, and can be used for SOME tools, but many tools don't report any ToolState numbers, and there is no commonality to the usage of ToolState numbers. (THERE SHOULD BE tho.. Google.. hint, hint!)

Alternative is to put new functionality in modules with a new name:

Code: Select all

module SU
  include Sketchup
  ... new methods ...
end