3 ms·

I'm sorry but he said to "backport it to 1.6" which would mean taking code from a more advanced version and making it work on an older codebase. This would invo

I'm sorry but he said to "backport it to 1.6" which would mean taking code from a more advanced version and making it work on an older codebase. This would involve updates to the 1.6 release or forking, which is what the other two "lol" comments in the thread are making fun of. If he would have said "re-implement it in your own app" I wouldn't have asked the question, and regardless, there's no need for the personal insults. A small part of ever community dies any time some random fanboy resorts to ad hominems. :)

mahmud 16y ago
I'm sorry but he said to "backport it to 1.6" which would mean taking code from a more advanced version and making it work on an older codebase. Out of a few possible meanings, you chose the most baroque. When writing portable code, you have a few approaches: 1) Target least-common denominator, and enable advanced features on richer targets ("Graceful Degradation"). 2) Target one platform/version maximally, and bundle your own abstraction layer for incompatible targets (Cygwin.) 3) Create your entire application in an environment created solely from a few, universally available primitives (a la Java Swing) or create your own ultra-portable runtime (java itself, Flash.) 4) Co-bundle a bunch of versions of the app for disparate platforms into one container format (Mac fat-binaries) -- this is the ugliest form of portability, almost analogous to ad-hoc polymorphism. 5) There are also self-improving systems that boot off simple stub code, and load more functionality from remote hosts, possibly compiling themselves on the new host, possibly using partial-evaluation and specialization, etc. As a programmer, your first instinct for making a piece of code portable should be along these lines. The idea of patching the world to accommodate your needs should never cross your mind. I would have loved to make this discussion about Android portability strategies. I mean, if MS-DOS 5 and 6.22 were binary compatible for device drivers, even though they used completely different device "models", then I am sure we can bump heads and exchange tricks for Android, iOS and other mobile OSes that are about to shatter like champagne glass on tarmac.

mahmud 16y ago

I'm sorry but he said to "backport it to 1.6" which would mean taking code from a more advanced version and making it work on an older codebase. Out of a few possible meanings, you chose the most baroque. When writing portable code, you have a few approaches: 1) Target least-common denominator, and enable advanced features on richer targets ("Graceful Degradation"). 2) Target one platform/version maximally, and bundle your own abstraction layer for incompatible targets (Cygwin.) 3) Create your entire application in an environment created solely from a few, universally available primitives (a la Java Swing) or create your own ultra-portable runtime (java itself, Flash.) 4) Co-bundle a bunch of versions of the app for disparate platforms into one container format (Mac fat-binaries) -- this is the ugliest form of portability, almost analogous to ad-hoc polymorphism. 5) There are also self-improving systems that boot off simple stub code, and load more functionality from remote hosts, possibly compiling themselves on the new host, possibly using partial-evaluation and specialization, etc. As a programmer, your first instinct for making a piece of code portable should be along these lines. The idea of patching the world to accommodate your needs should never cross your mind. I would have loved to make this discussion about Android portability strategies. I mean, if MS-DOS 5 and 6.22 were binary compatible for device drivers, even though they used completely different device "models", then I am sure we can bump heads and exchange tricks for Android, iOS and other mobile OSes that are about to shatter like champagne glass on tarmac.