Chris, check out the input/output ports of the virtual multiplexer that's fed the true/false from the conditional. The conditional puts out boolean but the virtual multiplexer puts out a 1/0, not a true false on the output. One can hover on the input node, (using index 1, the boolean chain) of the virtual multiplexer and see a 1/0 instead of a true/false... so there is definitely type conversion happening right at the input of the virtual multiplexer, converting boolean to numeric. It's seems like it's not so hands off! :o) I can see the argument that a boolean/numeric thing shouldn't break, but then that seems to leave functionality in an inconsistent state; there would basically be one exception to the rule. If I had something hooked up boolean, and published for a user, they have two options, and it will turn something on/off. If I change it to numeric without limiting the input splitter to 0/1, and having floating values available... now all of a sudden the user can do many things that create abnormal function. So... I think I lean towards the "noodle breaking". I can kind of see both sides of this one. Most the time it would be more convenient for me if it didn't break, but it can probably help prevent bad programming.
-George Toledo On Fri, Jun 26, 2009 at 12:54 PM, Christopher Wright <[email protected]>wrote: > Backing off a bit... why is there conversion going on after the first >> conversion? (note attachment). Notice how in the example, if you keep a >> multiplexer on virtual it converts the boolean input works fine, and is >> converted to numeric on the output of the multiplexer. So even though there >> is conversion going on in the second "chain", it still works fine. Without >> seeing your exact scenario it's a bit hard to say what the problem is. >> > > Passing through virtual ports (via splitters, muxers, etc) isn't really > doing a type conversion (passing through mathematical expression, which only > uses number ports, or example, or using indexes via javascript, would > perform an actual type conversion). The only unusual boolean port quirk > that I can think of is how any non-zero number is true (and this is > completely correct in a programmer sense, just not necessarily intuitive to > non-programmers). I don't think I've said there are any problems with it > (contrary to initial post) that would be involved in this -- it's just their > internals with regard to some assumptions Value Historian makes that I was > referring to (100% our bug). > > with Virtual Ports, you get out exactly what you put in -- the port itself > is hands-off. Typed splitters will do conversions (it's impossible to get a > 2 out of a boolean port, as it'll convert the 2 into a True and call it a > day). > > On a side note, I strongly disagree that connections severing when >> changing type is a bug. I think that's extremely functional (... it can be >> irritating, but I think it's the "right" thing to have happen). >> > > > I see this breaking into 2 cases: When you change from non-convertible > types (to/from structure, image from number, to illustrate a few), I think > breaking the connections is "right" (because you can't possibly expect > anything meaningful to happen this way). Other conversions that are > convertible, however, (bool < -> index <-> number) have no negatives, and > shouldn't break (in my opinion) -- what happens will be a tiny bit > different, but nothing catastrophic. > > -- > [ christopher wright ] > [email protected] > http://kineme.net/ > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
