[Code] Ruby Extension for Sketchup color integers

Dan Rathbun

This is an OPTIONAL extension for Ruby that helps deal with the differing formats for RGB, RGB0, RGBA and ARGB color integers. [For more info see this thread..]

It is a Ruby extension for Sketchup, not an extension to Sketchup per se.

I know that some of you just hate to modify base classes, BUT... that's what the power of Ruby is all about. (I DO intend to submit it to RubyForge for inclusion into standard ruby, but it would not make it in until after 2.0.x sometime.) In the meantime you can use it as an add-in.

The base class in question, is the Integer class, and it's subclasses Fixnum and Bignum.

Clarification: As discussed in the thread below... these methods really belong within the class to which they provide benefit and functionality. This class or classes, would be any Color object class that is defined in ruby, for whatever purpose. The example code can be rewritten slightly, so as to make it a generic mix-in module, for including in any Color class definition. In this way any Color class could inherit the conversion methods in the mixin module. Such a module would have as it's first line "module ColorIntegerConversion" instead of "class ::Integer", and this will be the way that it would be submitted for Standard Ruby, NOT as an extension to the ruby base Integer class.

The script is not scrambled. I place it in the public domain. No Warranty, etc.

STD_Fixnum_colorInts.rb

thomthom

I'd love to extend classes - would make allot more practical. But it's the potential for conflicts seeing how all scripts share the same space.
Additions of methods are one thing - use at own risk.
But modifications is a big no-no.

Very clean code though. Well documented.

fredo6

I agree with Tom.
We should NEVER extend built-in classes, especially the native Ruby ones.

You can perfectly publish your functionality as a custom class taking an integer parameter.
Alternatively, you can create a custom subclass of Integer, which contains the additional methods.

I am not familiar with color coding conversion, but I guess this applies in specific contexts, where you can perfectly accept to use specific variables created on purpose for this usage, through one or the other methods above.

Fredo

Dan Rathbun

@thomthom said:

Very clean code though. Well documented.

Thank you for the compliment sir!

After 32 years in Engineering Documentation, I probably tend to overdocument; slap revision numbers on everything.

This code is actually a triple exercise:

To see if the solution could be 'pure ruby.' (I think I proved it can be.) In this respect, it can also serve as an example.* Second; it's been say 20/25 years since I did anything in Assembler and still wanted to see if I could figure out how to 'move bits around.'* Lastly, I'm trying to learn the RDoc markup, and this was my 1st real attempt at putting that into code. I'm sure I made markup mistakes. The RDoc README info is vague... for instance, I can't figure out how to cause 'code blocks.' HTML tags?

thomthom

hmm... I was messing about with RDoc earlier. Can't remember from the top of my head right now. But I'll check out the examples I have bookmarked somewhere.

Dan Rathbun

Firstly, I stated in the 2 posts, (the root of this thread,) that it was OPTIONAL; and (in the API doc thread,) that it was TEMPORARY.
(I went back and re-emphasized those words in both posts, by bold caps.)

@unknownuser said:

You can perfectly publish your functionality as a custom class taking an integer parameter.
TRUE !! And this IS in the works. I've been working on the SKX extension for the Sketchup::Color class. These functions will be added in, because that's WHERE they REALLY belong! (I needed to write them up separately, for testing before adding them in. ...AND there's no way of telling when the first SKX release will happen.)

@unknownuser said:

Alternatively, you can create a custom subclass of Integer, which contains the additional methods.
Too cumbersome... the Color class method implementation is the norm.

@unknownuser said:

I am not familiar with color coding conversion, but I guess this applies in specific contexts, where you can perfectly accept to use specific variables created on purpose for this usage, through one or the other methods above.

To be honest, before this week, I thought there was only 1 way to represent colors as integers ( and Thom thought there was only 1 'other' way...) Research showed otherwise.
Now... these conversion principles are NOT my brainstorm (ie, invention.) Although I swear I authored the binary manipulation code in my methods without seeing what was done elsewhere. (What's the fun in figuring out the answer to a puzzle, if ya' cheat?)
If you look at the GDI+ library, you'll find that they already have similar functions built-in! But they are in C/C++, which requires you to use a Win32API call in order to use them. In addition, they are cumbersome to use, even in this way, because you would have to instantiate a GDI+ color object, in order to make use of their conversion methods.
The point is however, that in GDI+, these functions are class methods of the Gdiplus::Color class; and in the case of OpenGL, they would be class methods of the whatever C++ Color class wrapper is made (the standard OpenGL library is in C.) In the SU example, they set them up as the Sketchup::Color class.
Anyway.. I agree, they should be in the class to which they provide benefit or funtionality.

Dan Rathbun

Added to the original post (root of thread,):

Clarification: As discussed in the thread below... these methods really belong within the class to which they provide benefit and functionality. This class or classes, would be any Color object class that is defined in ruby, for whatever purpose. The example code can be rewritten slightly, so as to make it a generic mix-in module, for including in any Color class definition. In this way any Color class could inherit the conversion methods in the mixin module. Such a module would have as it's first line "module ColorIntegerConversion" instead of "class ::Integer", and this will be the way that it would be submitted for Standard Ruby, NOT as an extension to the ruby base Integer class.