It is expected for developers using API classes and their methods, to read the API documentation.
It is unexpected for a developer to not read the available resources, and then publicly declare the API to be deficient with respect to a certain feature.
It is expected for a developer to use their own good sense, experience and programming acumen to code their extensions in a way that works properly. (Ie, Trimble sells many kinds of products, but is not generally in the programming education business. They will however from time to time hold some developer “camps” to promote their APIs and their good use. But it is not Trimble’s responsibility to hold a developer’s hand and make sure their code works. This is the developer’s responsibility.)
It is most unexpected to have a developer believe that any certain tutorial would be the limit of knowledge surrounding the use of any API class, model or feature.
An example, is an example only. It shows something that can be done, but you as the programmer do not give up your own good sense of what must be done (in addition to what any example shows.)
Ruby is a dynamic language, therefor code objects can be changed unless you freeze your modules and classes.
You also need to protect your command methods (with licensing checks) which are fired from the toolbar buttons. The documentation mentions that a developer needs to put checks elsewhere in their code.
It is also possible to protect every single method (except public callbacks) in your code to only allow it to be called from within your code. (See: global method Kernel#caller and other methods in that module.)
Also, your extension sub-module belongs to you. There is no reason why you must leave introspective and reflective features active within your modules. Undefine or remove these kinds of methods before freezing your sub-modules. (Do not freeze your top-level namespace module, as it needs to be modified as sub-modules are added as extensions load.)
I know, I logged the issue, and I attempted to fix it but we’re having some issues with the YARD doc repo.
And then it seemed like, in the midst of us testing the new
Licensing class page, that some one at Trimble redirected the new good link (to the aforementioned tutorial,) to the Developer landing page. (@tt_su was going to check on that.)
The latest API doc changes (including the updates to the
Licensing class page,) have not yet been pushed to the public docs. (There were a bunch of other changes as well. But Thomas has been swamped with work of late.)
Well this is an issue for the Extension Manager interface. It is not a Ruby API bug. It’s an implementation issue for an application side interface. (So I would log it as an application bug against SketchUp itself. But I do agree, the"message" is ambiguous.)
However, the API docs for #error_description() say:
This is meant to aid in debugging only. Extensions should not rely on any exact error description.
So, they have not yet enumerated what the descriptions can be, nor what they mean.
This is all relatively new, with respect to the total age of the SketchUp Ruby API.
In other words they wish to “have license” (pun intended) to massage these, and perhaps also to localize these for the various languages builds. So do not test against them for conditional code branching. (Ie, think messagebox display only.)
Firstly, the documentation pages still need better information.
I believe that this is the probable “way of things”:
#state() when ext_lic.licensed? == true :
#state() when ext_lic.licensed? == false :
At least, this (above) is what would be the most obvious scenario (IMO.)
You decide how your code reacts to licensing state changes.
NO, plain and simple, … code defensively. (See the previous comments above.)
It cannot., which is WHY there is licensing interfaces in the API, for your code to use.
These are issues for the Extension Warehouse. Best to re-post in that category with a relation link back to this thread.