On Feb 18, 2012, at 4:32 PM, Matt Aimonetti wrote:
> One thing at a time, the only thing I said was that the GC is going away on
> OS X and that we need to find a way to not rely on libauto if we want MacRuby
> to run on future OS X releases. But there is no need to rush since the
> deprecation wouldn't happen until the release after MountainLion at the
> earliest.
Speaking just as an interested bystander here, I think there are other
compelling reasons to pursue ARC, of course. As you noted earlier, it's the
preferred way to manage memory in both OS X and iOS and obviously somewhat more
broadly applicable to the needs of the future. I think I'm only stating the
obvious when I say that MacRuby has always been somewhat hindered by the
implication (implicit in both its name and its use of OSX-only GC features)
that it would only ever be a solution for writing apps for OS X. Yes, that
may have also been the original goal, but that doesn't mean that the community
needs to continue to follow such a conservative roadmap. I've said it before
and I'll say it again: MacRuby is an OSS project and if its developers want to
take it somewhere it's never been or even rename it along the way (dropping
that somewhat limiting "Mac" prefix) then it should fully embrace such radical
notions since OSS projects are like sharks* - they either keep swimming or they
die. However, renaming stuff is also really hard (a lot harder than writing
code), so starting with a GC -> ARC transition seems like the logical place to
start!
> If we would have manually manage memory, that would be for me, a bit failure.
More than a bit. It would't be Ruby anymore. :-)
- Jordan
* This has actually been proven to be a myth about sharks, since many species
are more than capable of lying on the bottom without suffocating, but it makes
such a great analogy that we keep using it. :)
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
