Understanding Attribute DIctionaries(?)

Developers Ruby API
12

Have you stopped to consider that YOU are only one confused here ? Or that YOU are purposely creating the confusion (via topic inveiglement,) because you do not like the use of the word “dictionary” ?

You can call (refer to) objects by whatever local identifiers makes you feel “warm and fuzzy”.

module BMDroid
  module SomePlugin

    # Refer to the class by my own "nickname":
    DataStickers = Sketchup::AttributeDictionary

  end
end

But, don’t expect the rest of the SketchUp coding world to follow your example. For a myriad of reasons:

  • We don’t actually refer to these classes by class identifier. (Ie, their constructors are wrapped within the functionality of accessor instance methods.) So, the point is moot.

  • Again and again, the SketchUp development team has tried to explain that their philosophy is a minimalist core that is extensible. (This also applies to the SketchUp APIs.) So,…

    • It matters not what gargantuan Microsoft (with their thousands of programmers) calls their attribute collection objects in their Visio VB API, …

    • nor what huge AutoDesk (with their hundreds of programmers) calls their attribute collection objects in their various AutoCAD APIs, … because the extension code is not transportable between these applications and SketchUp.

  • The API class names are not renamed when, for example, features are renamed in the user interface. (Ie, Sketchup::Page was renamed in the GUI to “Scene”, but remains in the API with the historical classname.) Arbitrary renaming would break thousands of plugins “out in the wild.”

  • There is like 12 years of online documentation and forum discussions using the current classname. Do you wish to track all that down and attach some notice of a name change ? I don’t think so.

This is your idea on what this class should be, (based upon your past experience with other product APIs, and what they called a “dictionary.”)

But if they were like this, they’d likely be much less powerful, and not as flexible. Some of the rendering extensions may not have been able to save the kinds of data that they do in SketchUp’s attribute collection objects, if they were more strongly typed.

Firstly, the basic definition of a dictionary, is simply a list (collection) of terms and their definitions. The printed form is for human consumption and is usually ordered alphabetically. But the computer form is made up of key-value pairs, and is accessed by the key.

The real underlying question for this whole topic thread (and what you should have asked in the opening post, instead of inveigling us into this worthless argument about what a “dictionary” should be,) is:

Why does the Sketchup::AttributeDictionary API class use the word “Dictionary” in it’s name?

Because SketchUp is programmed in C++ as an MFC application.

The SketchUp Ruby API is made up of many wrappers of C++ objects. In many cases the names of the wrapper classes or methods, just used the underlying C++ name (or something similar.)

It may not make sense to you, Barry, but it does to the C++ core programmers maintaining the code (both for the SketchUp engine and the API interfaces.)

Yes, because they were designed to be this way, by Microsoft (or the inventors of C++.)

If you look at the MSDN page, you’ll see that they were designed to be compatible with basic database tables.

They are simply lists of key / values pairs, and are one of the basic forms of data collections in all of programming. (They can be called by different names in different programming languages / environments. Ie, Struct, Hash, HashTable, Table, etc.)

It also likely makes them the most compatible that they can be when exported to various file formats.

So the name was not chosen to mimic AutoCAD APIs, nor to mimic Visio VB, nor to confuse anyone who makes intransigent assertions that anything using the word “dictionary” in it’s name, must conform to their idea of what a dictionary should be, or must conform to what some other applications call a “dictionary”.

The class comes with a basic set of accessor and iterator methods, and in addition, does inherit methods from it’s ancestors.

Sketchup::AttributeDictionary.ancestors

outputs:

 Enumerable,
 Sketchup::Entity,
 Object, 
 JSON::Ext::Generator::GeneratorMethods::Object,
 Kernel,
 BasicObject

So it has all the nice methods from the Enumerable mixin module, and all it’s other ancestor superclasses.

But the SketchUp API documentation does not document the Ruby core objects and methods. You need to refer to Ruby core documentation for this.

I agree that in SketchUp programming, GUI programming and input validation can be tedious and boring, but others have already been there, and done that. ThomThom wrote a GUI library that leverages UI::WebDialog “under it’s hood” but is used in a more Ruby-ish way. It may even have built-in validation as he wrote a good tutorial on this at his blogsite.

If he can do it, so can others, and so can you.

Nothing stops you from writing your own helper class to do input validation. Or from using ThomThom’s libs. Or someone else’s.

It would be more difficult for coders to create wrapper or helper classes if the dictionary class was not as basic as it is.

2 Likes