Seeing 'String' instead of <NSCFString = 0x02CC9330> and 'Number' instead of <NSCFNumber = 0x02CC9330> would aid human-eye-parsing of the virtual object structure in my view. Sometimes virtual types seem to be explicitly displayed if we go further down the graph towards the renderer. This is a one item object which is a string so maybe it's the exception to the rule.
<<inline: Virtual.jpg>>
I can bug if it's worthwhile? On 04/08/2010, at 3:17 PM, Christopher Wright wrote:
Hmm, this is the only way we can currently see what the data actually is. Does this really need to be "fixed"? The reason behind the difference in data type representation should be clear if one takes the time to look at the port type.But do you care what the data actually is (other than for curiosity)? Generally, you're more interested in whether or not the data "speaks your language" (i.e. had keys/indices if it's a structure, has components if it's a color, has a length if it's a string, etc). Note how the strings in the shot are NSCFStrings -- what are those, exactly? a private class with no documentation. But they're useful because they _act_ like NSStrings (they have a length, and characters, and all the other stringy properties that make NSString useful).QC could plausibly abstract away structures and strings and number and colors behind an opaque "QCObject" type, and it'd be pretty useless to see their type in tooltips (you'd just see "QCObject <0x12345000>"). [note: if I do that, please vote me off the island for being insane ;](This philosophy is known as "duck typing" -- for better or worse, it's here to stay, and plays a major role in modern objective-C applications/frameworks).Since it's pretty trivial to figure out what the data is on a virtual port, I think it'd be nicer if the tooltips always showed the pretty version (to me, seeing "title" = "Breakfast at Tiffany's" is dramatically more useful than "title" = "<NSCFString - 0xBADBEEF0>").-- Christopher Wright [email protected] _______________________________________________ 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/qc.student.au%40gmail.com This email sent to [email protected]
_______________________________________________ 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]
