<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for David Young</title><link>http://disqus.com/people/d24ec97b91c8ebfc6888e68addb40f69/</link><description></description><language>en</language><lastBuildDate>Tue, 31 Oct 2006 00:46:38 -0000</lastBuildDate><item><title>Re: Obligatory WWDC Wrap-Up and Leopard Analysis</title><link>http://toxicsoftware.disqus.com/obligatory_wwdc_wrap_up_and_leopard_analysis/#comment-1655993</link><description>In the past, Apple has implemented a lot of the methods which I'd usually attach to the kits with categories. But yeah, this can happen with any bit of code -- Cocoa changes so quickly these days!&lt;br&gt;&lt;br&gt;When the new release ships with the stuff which obsoletes the old code, I try to make the old code perform as closely to Apple's implementation as I can, and toss it in the "compatibility" bin. You never know when you'll have to support some legacy release. It's still too early to call what the Leopard adoption rate will be (although I don't doubt that it'll be great -- I don't think we saw 20% of the user-facing features at WWDC), so that code will continue to be worthwhile until at least a year from now. If it's good, well-tested code, it'll continue to be worthwhile until at least 10.5.3. ;)&lt;br&gt;&lt;br&gt;Usually I ditch code that's two major OS releases old, chances are it hasn't seen much action lately anyway and bugs have doubtless crept in. And I'm not sure what you're obsoleting, but there is something that's coming that's replacing something you might be thinking of obsoleting because it's internally nasty, but someone said it would be available independently of an OS release, as it usually is for this something. (I didn't say anything)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">David Young</dc:creator><pubDate>Thu, 17 Aug 2006 02:22:57 -0000</pubDate></item><item><title>Re: Second Hand Smoke</title><link>http://toxicsoftware.disqus.com/second_hand_smoke/#comment-1656019</link><description>I dunno man, while it's true that anyone with class-dump could've reverse-engineered Smoke.framework on their own, it certainly looks like a lot of effort went into engineering it. Ripping it off (especially if one were to link to the framework and redistribute it) seems pretty uncool. If I were the developer, and the smoke effect turned up in a bunch of applications, I probably wouln't waste money on a lawyer, but I wouldn't be happy either.&lt;br&gt;&lt;br&gt;But, if you've chatted with one of the developers and he/she says it's okay, no harm done. Have the developers really confirmed that they meant for other developers to use Smoke.framework? (Having removed the headers from the shipping product indicates to me that the answer is probably no...)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">David Young</dc:creator><pubDate>Tue, 31 Oct 2006 00:46:38 -0000</pubDate></item></channel></rss>