Revolution Snippet Properties

Gotcha. Yeah, we could probably built them in in the future.

Hardheaded? Never.

My reason for trying to bulletproof things is selfish. I don’t want to have to explain to countless users why their snippets don’t work. I do see the trade-offs though, especially when it comes to performance and backward compatibility.

So -- points taken, although I still contend that making sure the properties grid UI refuses to store anything but "0" and "1" for booleans is cheap insurance with no practical performance consequences.

Doing the same in setProperties() (at least to the point of putting in something like the following *only for booleans* ) also seems pretty cheap since it will rarely run outside of a build, but maybe there’s something I’m missing on that point.

Why not have your cake and eat it too with a "normal" boolean that allows anything and a binary boolean that only stores 0/1?

Quote from: rthrash at Nov 06, 2008, 02:45 PM

Why not have your cake and eat it too with a "normal" boolean that allows anything and a binary boolean that only stores 0/1?

You can; we’ll validate the ’boolean’ type to return ’0’ or ’1’ (as BobRay suggests) and you can create a ’combo’ type with any other custom approach to representing boolean values you want to take. We can also validate that a value is one of the valid options for default properties as well. But it will still be 100% the responsibility of each component to make sure any tag values provided to override the defaults are valid options.

Quote from: OpenGeek at Nov 06, 2008, 02:51 PM

Quote from: rthrash at Nov 06, 2008, 02:45 PM

Why not have your cake and eat it too with a "normal" boolean that allows anything and a binary boolean that only stores 0/1?

You can; we’ll validate the ’boolean’ type to return ’0’ or ’1’ (as BobRay suggests) and you can create a ’combo’ type with any other custom approach to representing boolean values you want to take.  We can also validate that a value is one of the valid options for default properties as well.  But it will still be 100% the responsibility of each component to make sure any tag values provided to override the defaults are valid options.

Well, now I feel dumb. I think I just realized (finally) what "combo-boolean" actually means (sound of hand hitting forehead). 

I withdraw most of what I said earlier about booleans (including my strong opinion about the need for another ’boolean’ type). I’ll have to play some with the "options" and the implementation to have an informed opinion on this.

After messing with splittingred’s fabulous implementation of the grid and setting some properties in the grid and with setProperties(), I have to say that the current choices do everything I’d ever need and provide a very clear UI. Since the values for "Yes/No" types are stored as 0 and 1, adding a pure boolean type might just confuse things.