GNUstep 支持@property 和@synthesize 吗？
我正在开发一个 Cocoa 应用程序，目的是使用 GNUstep 在 Windows 和 Linux 上使用它。 到目前为止，我一直在避免使用 Objective-C 2.0 功能，但我真的很想至少开始使用属性。 Google 似乎告诉我（尽管我在这个主题上找不到太多内容）是目前没有 Objective-C 2.0 功能可与 GNUstep 配合使用。 有谁知道 GNUstep 是否有支持 @property 和 @synthesize 的计划？
我也想知道是否有一个好的策略来“扩展”它们？ 我当然可以想象一个程序可以使用 @property 和 @synthesize 将代码扩展为不使用任何 Objective-C 2.0 功能的代码，但我担心对这样的事情没有太多需求，所以我可能不会'找不到一个。
您认为 GNUstep 在明年左右支持 @property 和 @synthesize 的可能性大吗？
I'm working on a Cocoa app with the intention of using it on Windows and Linux using GNUstep. I've been avoiding Objective-C 2.0 features thus far, but I'd really love to start using at least properties. What Google seems to tell me (though I'm having trouble finding much on the subject) is that currently, no Objective-C 2.0 features work with GNUstep. Does anyone know if there are plans for GNUstep to support @property and @synthesize?
I also wonder if there is a good strategy for "expanding" them? I could certainly imagine a program that could expand code using @property and @synthesize into code that does not use any Objective-C 2.0 features, but I'm worried there isn't much demand for such a thing, so I probably won't be able to find one.
Do you think there is a good chance that GNUstep will support @property and @synthesize in the next year or so?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不确定 Objective-C 的 GNUstep 实现是否会追随 Apple 在访问器/变异器合成方面的领先地位，但如果您想为 Mac、Windows 和 Linux 制作应用程序，GNUstep 可能不是最佳选择。 将代码从 Cocoa 移植到 GNUstep 应该很容易（您甚至可以编写宏来转换属性声明），但很少有人在 Linux 上使用 GNUstep，在 Windows 上使用 GNUstep 的人就更少了。 我喜欢跨平台 OpenStep 实现的想法，但目前它在采用方面还不太实用。
I am not sure whether or not the GNUstep implementation of Objective-C will follow Apple's lead in accessor/mutator synthesis, but if you are trying to make an app for Mac, Windows and Linux, GNUstep is probably not the best choice. It should be pretty easy to port the code from Cocoa to GNUstep (and you might be able to even write a macro to convert your property declarations), but very few people use GNUstep on Linux and even fewer on Windows. I love the idea of a cross-platform OpenStep implementation, but at the moment, it isn't really practical, adoption-wise.
虽然晚了几个月，但答案是肯定的； GNUstep 将支持 Objective-C 2.0 功能（以及块）。 目前，一切都已基本实现，但还需要测试和调试。 这些功能需要 Clang 而不是 gcc，目前您需要使用 trunk 版本。
有关更多详细信息，请参阅 David Chisnall 在该线程中的解释：
http://groups.google.com/group/gnu。 gnustep.discuss/browse_thread/thread/b0a5fa4e3be71bb1#
This is a few months late, but the answer is yes; GNUstep will support Objective-C 2.0 features (as well as blocks). Currently, everything is more or less implemented, but needs testing and debugging. These features require Clang rather than gcc, and currently you need to use the trunk version.
See David Chisnall's explanation in this thread for more details:
http://groups.google.com/group/gnu.gnustep.discuss/browse_thread/thread/b0a5fa4e3be71bb1#
不，我不知道是否有计划支持属性，但如果 GNUstep 计划保持可行（即使只是在目前有限的程度上），这应该是一个优先事项。 除非 GNUstep 决定采用 Objective-C 2.0 特性，否则它与 Apple 实现之间的差距将使编写良好的跨平台代码变得越来越困难。 （对于大多数开发人员来说，这已经是毫无意义的了。）
虽然我通常讨厌那些本质上说“不要这样做，这是一个坏主意”的答案，但我必须同意@Jonathan 在这一点上的观点，特别是从实用性的角度来看。 尽管代码可以跨平台编译，但如果用户必须安装运行时才能使用您的应用程序，那么有人使用您的应用程序的可能性就会大大降低。
这个答案很好地总结了这一点。 我建议阅读它并得出自己的结论。
还值得考虑的是，“objective-c” 标签有超过 3280 个问题，而 “gnustep” 有 9。我并不是说问题量是质量的衡量标准，但它与活动和兴趣平行，并且相当该站点上具有 GNUstep 专业知识的人员可能很少。 因此，如果您选择走您正在考虑的道路，您就不太可能获得良好的帮助。
顺便说一句，以兼容性的名义避免新功能的心态是一种“最小公分母”行为，从长远来看，会让你的代码变得不那么优雅，也不那么“有特色”。 这类似于仅使用 10.2 或 10.3 上可用的 API 进行编码 — 任何最近使用 OS X 或 iPhone 的开发人员都会告诉您，他们宁愿利用这些很酷的新功能，而不会受到过去限制的阻碍。 如今，新应用程序几乎总是需要 10.5 - 对旧版本的支持是向后兼容的既定软件的更多特征，许多应用程序甚至随着时间的推移而放弃旧操作系统。
如果您正在考虑销售应用程序，则仅使用 GNUstep 兼容的 API 将严重限制您的市场，甚至从根本上限制您的应用程序，包括您希望实现的完善程度和功能。 即使应用程序不会商业化，使用最适合给定平台的语言和框架通常也有其优点。 如果您确实正在寻求跨平台支持，那么 Java 可能会更接近您，而且不会让您感到头疼。 （Java 绝对不是我最喜欢的语言，它也不是 Cocoa，但它在很多事情上做得很好。）尽管跨客户端和平台仍然存在相同的语言版本问题，但至少它设计是跨平台，所有消费平台都有可靠的 Java 支持。
No, I don't know whether there are plans to support properties, but if GNUstep plans to stay viable (even if only in the limited degree to which it is now) this should be a priority. Unless GNUstep decides to adopt Objective-C 2.0 features, the gap between it and Apple's implementation will make it increasingly difficult to write good cross-platform code. (It's already borderline pointless for most developers.)
Although I usually hate answers that essentially say "don't do that, it's a bad idea", I have to agree with @Jonathan on this one, especially from the standpoint of practicality. Although the code may compile cross-platform, if users have to install a runtime just to use your app, the probability that someone will use your app is vastly diminished.
This SO answer sums it up nicely. I suggest reading it and draw your own conclusion.
It's also worth considering that the "objective-c" tag has over 3280 questions, while "gnustep" has 9. I'm not saying that question volume is a metric of quality, but it is a parallel with activity and interest, and quite possibly a low number of people with expertise in GNUstep on this site. Thus, you're less likely to get good help if you choose to go down the path you're considering.
By the way, the mentality of avoiding new features in the name of compatibility is a "least common denominator" behavior that, in the long run, will make your code less elegant and less "featureful". It's similar to only coding with APIs available on 10.2 or 10.3 — any recent OS X or iPhone developer will tell you they'd rather take advantage of the cool new features, and not be hampered by past limitations. These days, new apps almost always require 10.5 — support for older versions is more characteristic of established software that is being backward compatible, and many apps even drop old OS's over time.
If you're considering selling an application, using only GNUstep-compatible APIs will severely limit your market, and even limit your app in fundamental ways, including the level of polish and functionality you can hope to achieve. Even if the app won't be commercial, there is generally merit to using the language and frameworks that are the best fit for a given platform. If you're really looking for cross-platform support, Java is likely to get you closer with less heartburn. (Java is definitely not my favorite language, and it's not Cocoa, but it does many things well.) Although there is still the same problem of language version across clients and platforms, at least it's designed to be cross-platform, and all consumer platforms have solid Java support.