That one exception is because the string info is available in the Description (note it's still not represented as a structure". This is what I was referring to as namespace info (which we can't actually gain access to... it just so happens that the two match up in this case; the namespace info as well as the actual output from that port.
-GT On Wed, Aug 4, 2010 at 1:43 AM, Alastair Leith <[email protected]>wrote: > I guess sometimes it sufficient to see the 'shape' of a structure eg. it's > an array of items each item seems to have a "title" which is a string type > and a "description" which is a string type etc etc and sometimes you hoping > to be able to read the data as text if that is possible to get more of a > clue about what's happening. > > 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. > > > > > > 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/gtoledo3%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]
