Re: ObjC's flat and all-exported namespace, help!
On 10/11/2011, at 12:04 PM, Ian Joyner wrote: It's the old I have a hammer so everything looks like a nail, but in C++'s case it's I have a programming language, so everything gets put in that. We really need to get away from that kind of thinking about programming languages and get back towards the Smalltalk ideal. Objective-C does that, which makes it the nicest flavour of C. The programming community needs to learn what the phrase 'separation of concerns' really means. Hear hear! Sure, Objective C exposes a lot of internals for those who are looking for it. So does any language to somebody with a good debugger. Don’t think you’re safe if you program in C or C++. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On Nov 10, 2011, at 2:04 AM, Ian Joyner wrote: snip So, in other words, you prefer polymorphic runtime resolved symbols over compile-time resolved symbols (like in C++). I just don't understand, why this makes C++ namespace syntax ugly, and why you still state that C++ namespace is inflexible and problematic, and inflict more issues than it solves. While this is not true (IMO), I don't understand what this (and Windows, C pointers, and gotos, etc.) has to do with a new namespace feature for Objective-C/C++. I fear these divagations are contra-productive. The programming community needs to learn what the phrase 'separation of concerns' really means. I would certainly agree about some polymorphic dynamically resolved namespace feature in Objective-C. I'm awaiting your lecture. Andreas___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On 10 Nov 2011, at 21:13, Karl Goiser wrote: On 10/11/2011, at 12:04 PM, Ian Joyner wrote: It's the old I have a hammer so everything looks like a nail, but in C++'s case it's I have a programming language, so everything gets put in that. We really need to get away from that kind of thinking about programming languages and get back towards the Smalltalk ideal. Objective-C does that, which makes it the nicest flavour of C. The programming community needs to learn what the phrase 'separation of concerns' really means. Hear hear! Sure, Objective C exposes a lot of internals for those who are looking for it. Yes, that's troubling in a way, but if it is separated it is maybe alright. However, I have problems with systems that seem to say here is nice high-level programming, but here's a way to subvert it. Layers and paradigms should be kept separate. If one paradigm is cross-bred with another, both paradigms lose their meaning and things begin to break down. So does any language to somebody with a good debugger. Yes, there's no problem with knowing the lower level. On B5000 machines I knew the runtime well, could pretty much say what machine code any line of ALGOL would generate, could find my way around system dumps, far easier than on any other machine I have coded on. But did ALGOL ever need the programmer to subvert it at an assembler level? No. There WASN'T even an assembler. Thus the whole system was a self-contained package and you never needed to subvert the paradigm. Now that's a cohesive system. Seems when we need to dig around in internals the system is not actually cohesive. Don’t think you’re safe if you program in C or C++. Never. C and C++ are the biggest reason for the sorry state of security we have on systems these days. As Bob Barton noted Systems programmers are the high priests of a low cult http://www.computer.org/portal/web/csdl/doi/10.1109/MC.1980.1653540 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On 10 Nov 2011, at 21:22, Andreas Grosam wrote: On Nov 10, 2011, at 2:04 AM, Ian Joyner wrote: snip So, in other words, you prefer polymorphic runtime resolved symbols over compile-time resolved symbols (like in C++). Not saying that at all, and don't really agree with that. If a compiler can statically analyze things and resolve at compile time, that's good for optimization and statically-typed languages can do that. But for full type flexibility, we need to defer some cases until run time. I just don't understand, why this makes C++ namespace syntax ugly, and why you still state that C++ namespace is inflexible and problematic, and inflict more issues than it solves. Because this is trying to solve a problem at the programming level that should not be at the programming level. It's putting the concern of name clash avoidance throughout the code. That's not a good place to solve this problem. It's an ugly solution. Eiffel solves these kinds of problems externally to the language, so that program code is kept clean. While this is not true (IMO), I don't understand what this (and Windows, C pointers, and gotos, etc.) has to do with a new namespace feature for Objective-C/C++. Because like badly done gotos, you get this concern interwoven throughout the code. That is just not clean code. That's why aspect-oriented programming removes certain aspects from the code and uses the technique of weaving to automatically put it back in. C++ does everything the bone-headed way. We have a problem, so let's solve it with another language construct. No programming languages should be kept simple and issues of organization kept external. John Backus has a nice quote in: http://www.stanford.edu/class/cs242/readings/backus.pdf For twenty years programming languages have been steadily progressing toward their present condition of obesity; as a result, the study and invention of programming languages has lost much of its excitement. Instead, it is now the province of those who prefer to work with thick compendia of details rather than wrestle with new ideas. Discussions about programming languages often resemble medieval debates about the number of angels that can dance on the head of a pin instead of exciting contests between fundamentally differing concepts. Namespaces is just trying to make something else dance on the head of this pin. I fear these divagations are contra-productive. Why? Because someone points out that namespaces are a bad idea and tells you why? The programming community needs to learn what the phrase 'separation of concerns' really means. I would certainly agree about some polymorphic dynamically resolved namespace feature in Objective-C. I'm awaiting your lecture. No, I've given enough lectures in the last few days. Undergrads seem to enjoy thinking differently with heretical ideas and why in a class on software project management I'm telling them management is a bad idea and is a doomed class! We really should be in the obj-c newsgroup. Ian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On Nov 9, 2011, at 9:36 AM, Andy O'Meara wrote: Well, if you have a serial number/license scheme, copy-protection scheme, crypto, or payment mechanisms that use objC, then realize they're on display for everyone to see. Use functions instead of a class to restrict the amount of information exported. Here is a good article on making your application less vulnerable to attacks. http://unsanity.org/archives/000101.php --Richard ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
Unfortunately the problem is that when you sell and ship commercial software, shipped software can't look into the future. The real aspect of this issue, that I raised in my initial post, is that third party developers such as ourselves internally reuse various support classes for multiple bundle products, so when the host loads our products this issue surfaces. And yes, this thread does belong on the objC list and will be moving it there (I didn't realize there was a objC list when I originally posted). On Nov 9, 2011, at 12:08 AM, Karl Goiser wrote: I think there is another solution that doesn’t involve making the language more complicated: I would complain to the suppliers of the bundles with conflicting class names. They know they are delivering into an environment with a flat namespace. It is up to them to defend against this sort of problem. It’s their fault that this problem is occurring. Karl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/andrew.omeara%40soundspectrum.com This email sent to andrew.ome...@soundspectrum.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
rdar://problem/2821039 ER: Objective-C namespaces If you're familiar with Radar numbers, you'll recognize that the bug is very old. The name is a bit misleading - C++ namespaces or Java packages are little better than adding name prefixes by hand. (For example, they don't solve the problem of two developers importing the same static archive.) A real solution for class name collisions needs to be (1) automatic or nearly so, (2) predictable so nib references work, and (3) not incompatible with existing classes. It's a hard problem. Cool, thanks for posting Greg. Yeah, there seems to be a lot roadblocks to dealing with this, but my point was more to suggest that simply allowing bundles to only publish classes explicitly is an easy way to address that it's generally the *support* classes that need to be private/hidden by default. I think developers will do a good job to ensure that exported class names are unique, but it's all a developer's *support* classes that are likely to have issues. The aspect of concern of this issue is that third party developers such as ourselves internally reuse various support classes for multiple bundle products, so when the host loads our products this issue always appears, users panic over log messages they don't understand, and dork OCD devs like me feel icky that the namespace is being spammed unnecessarily. So as you initially pointed out, I've gone with making a C mangler macro approach. It wasn't too painful, but I do think it is a bit of an oversight that there's no way to disable all objC classes from being public by default. Andy___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
Le 9 nov. 2011 à 09:14, Andy O'Meara a écrit : Unfortunately the problem is that when you sell and ship commercial software, shipped software can't look into the future. The real aspect of this issue, that I raised in my initial post, is that third party developers such as ourselves internally reuse various support classes for multiple bundle products, so when the host loads our products this issue surfaces. And yes, this thread does belong on the objC list and will be moving it there (I didn't realize there was a objC list when I originally posted). Before starting a discussion on the obj-c list, you may want to read the following thread from the clang mailing list: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-November/012026.html It may contain good answers to your questions about obj-c namespaces. On Nov 9, 2011, at 12:08 AM, Karl Goiser wrote: I think there is another solution that doesn’t involve making the language more complicated: I would complain to the suppliers of the bundles with conflicting class names. They know they are delivering into an environment with a flat namespace. It is up to them to defend against this sort of problem. It’s their fault that this problem is occurring. Karl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/andrew.omeara%40soundspectrum.com This email sent to andrew.ome...@soundspectrum.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org This email sent to devli...@shadowlab.org -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
.. so if you prefix all your classes with your company name, the only conflicts will be with the same class from different bundles, which means that only one instance of any class will be loaded, thus saving memory on every client’s machine… Yes? On 09/11/2011, at 7:14 PM, Andy O'Meara wrote: Unfortunately the problem is that when you sell and ship commercial software, shipped software can't look into the future. The real aspect of this issue, that I raised in my initial post, is that third party developers such as ourselves internally reuse various support classes for multiple bundle products, so when the host loads our products this issue surfaces. And yes, this thread does belong on the objC list and will be moving it there (I didn't realize there was a objC list when I originally posted). On Nov 9, 2011, at 12:08 AM, Karl Goiser wrote: I think there is another solution that doesn’t involve making the language more complicated: I would complain to the suppliers of the bundles with conflicting class names. They know they are delivering into an environment with a flat namespace. It is up to them to defend against this sort of problem. It’s their fault that this problem is occurring. Karl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/andrew.omeara%40soundspectrum.com This email sent to andrew.ome...@soundspectrum.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
Le 9 nov. 2011 à 10:11, Karl Goiser a écrit : .. so if you prefix all your classes with your company name, the only conflicts will be with the same class from different bundles, which means that only one instance of any class will be loaded, thus saving memory on every client’s machine… Yes? It wont prevent clash if two bundles use different versions of the same class. On 09/11/2011, at 7:14 PM, Andy O'Meara wrote: Unfortunately the problem is that when you sell and ship commercial software, shipped software can't look into the future. The real aspect of this issue, that I raised in my initial post, is that third party developers such as ourselves internally reuse various support classes for multiple bundle products, so when the host loads our products this issue surfaces. And yes, this thread does belong on the objC list and will be moving it there (I didn't realize there was a objC list when I originally posted). On Nov 9, 2011, at 12:08 AM, Karl Goiser wrote: I think there is another solution that doesn’t involve making the language more complicated: I would complain to the suppliers of the bundles with conflicting class names. They know they are delivering into an environment with a flat namespace. It is up to them to defend against this sort of problem. It’s their fault that this problem is occurring. Karl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/andrew.omeara%40soundspectrum.com This email sent to andrew.ome...@soundspectrum.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org This email sent to devli...@shadowlab.org -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On Nov 9, 2011, at 10:11 AM, Karl Goiser wrote:
.. so if you prefix all your classes with your company name, the only
conflicts will be with the same class from different bundles, which means
that only one instance of any class will be loaded, thus saving memory on
every client’s machine…
Yes?
It seems, you like this:
// File: com_example_company_appsuite_Bar.m
// private class
@interface com_example_company_appsuite_Bar_detail_Foo
@end
…
@implementation com_example_company_appsuite_Bar
// private method
- (void) doSomethingWithFoo:(com_example_company_appsuite_Bar_detail_Foo*) foo
{
com_example_company_appsuite_Bar_detail_Foo* fooCopy = [foo copy];
...
}
Where it **could** look like this:
namespace example_company { namespace appsuite {
namespace Bar_detail {
@interface Foo
@end
...
}
@implementation Bar
using Bar_detail::Foo;
// private method
- (void) doSomethingWithFoo:(Foo*) foo
{
Foo* fooCopy = [foo copy];
...
}
}}
Andreas
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
Your first option looks better to me! :-) All I’m saying is that Objective C is a very mature language now and if it has been able to get by without adding this extra layer of complexity, why introduce it for an edge case to address a situation where people are expecting it to act like C++? Apple, after all is all about being simple and clean, and its language of choice should reflect that because, after all, it’s the developers who create the simple and clean. In my opinion, Objective C is an embodiment of the Apple attitude. My favourite saying of all time is, “to a person with a hammer, everything looks like a nail.” Objective C is a screw, and you use a screwdriver on it, nor a hammer. As far as versioning issues from the same class in two bundles is concerned, if the class works to spec, there’s no problem. If it doesn’t, that’s a bug, and wouldn’t the bundles have to be updated anyway? Karl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On Nov 9, 2011, at 12:11 PM, Karl Goiser wrote: Your first option looks better to me! :-) All I’m saying is that Objective C is a very mature language now Depending on your perspective, you can say this for many languages. But only the dead ones do not evolve (Objective-C, does it, though) and if it has been able to get by You should ask the *developers*, not the *language*, if they experience issues and if they feel comfortable to workaround these issues. without adding this extra layer of complexity, why introduce it for an edge case to address a situation where people are expecting it to act like C++? I wouldn't say it is an edge case. If you develop small applications in a one-man company, and no plugins, you may feel this as a minor issue. Others won't agree, and actually have a big problem. Namespaces for Objective-C will likely not require the same feature set than what is available in C++ (e.g., no argument dependent lookup). There is also no need to do this. The only thing that should be considered when introducing namespaces in my opinion is, that it should be seamlessly integrated into Objective-C++. The negative asset against C++ made from a few posters here, is futile - Objective-C will have and be Objective-C++ as well. This requires to consider C++ syntax - and IMHO, regarding namespaces, it isn't ugly at all. Apple, after all is all about being simple and clean, and its language of choice should reflect that because, after all, it’s the developers who create the simple and clean. In my opinion, Objective C is an embodiment of the Apple attitude. From the developers view, using namespaces shouldn't appear to be complex and its usage should be certainly optional. IMHO, Objective-C could stay without having namespaces. C is required to use the same approach to avoid name conflicts: prefixes. However, introducing namespaces to Objective-C++ could be worthwhile to investigate if this is feasable. IFF, then integrating namespaces with C++ possibly could be done seamlessly. Andreas My favourite saying of all time is, “to a person with a hammer, everything looks like a nail.” Objective C is a screw, and you use a screwdriver on it, nor a hammer. As far as versioning issues from the same class in two bundles is concerned, if the class works to spec, there’s no problem. If it doesn’t, that’s a bug, and wouldn’t the bundles have to be updated anyway? Karl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On Nov 9, 2011, at 3:44 AM, Andreas Grosam agro...@onlinehome.de wrote: On Nov 9, 2011, at 12:11 PM, Karl Goiser wrote: without adding this extra layer of complexity, why introduce it for an edge case to address a situation where people are expecting it to act like C++? I wouldn't say it is an edge case. If you develop small applications in a one-man company, and no plugins, you may feel this as a minor issue. Others won't agree, and actually have a big problem. Remember the original case that prompted this discussion: the screen saver engine loading two different screen saver bundles that define different versions of classes with the same name. The same situation can arise with Quick Look: the Quick Look daemon might reuse worker processes. If you have two apps installed whose generators use different versions of the same framework, you could get a conflict. This really isn't an edge case. --Kyle Sluder___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
Interesting, thanks. I think the side of this that typical OS X developers is that their own internal classes from multiple bundle products are the bulk of the issue, not for the objC bundle loading mechanism to get a fancy namespace overhaul (which is understandably a huge undertaking). I suppose what we've discovered--or at least what I've discovered--in this thread is that because addressing this issue is so huge from the namespace spec side, the answer seems to be the path of expanding @private to mark up an entire class. Depending on the mechanics and details of how the objC binary is structured, the bundle's linker would either omit the names of those classes from the symbol list or it would emit a flag, indicating that the loader should skip that class entry. The former makes more sense for security/snooping reasons (and to people who don't see the value in that, allow me to suggest that quite a lot can be learned about an app or bundle by looking through its class and method tables). Speaking of that, to folks here that think this stuff is boring or isn't relevant to their products, please take a moment and realize that every objC class and method name are public and completely visible to anyone that owns a text editor (let alone a decent disassembler). Still don't care? Well, if you have a serial number/license scheme, copy-protection scheme, crypto, or payment mechanisms that use objC, then realize they're on display for everyone to see. We make cross-platform software, so the bulk of our code is in C++ frameworks, but most projects out there have god and country exposed for the world to see and their authors often don't even realize it. Worse, the default setting in Xcode is for all C/C++ symbols to be exported by default so add that to the mix too. Admittedly, we care about these issues more than the next dev because we sell software in one of the most highly pirated areas of software, but hopefully bringing this up here helps raise some awareness from devs that don't normally think about this stuff. Happy trails! On Nov 9, 2011, at 2:54 AM, Jean-Daniel Dupas wrote: Le 9 nov. 2011 à 09:14, Andy O'Meara a écrit : Unfortunately the problem is that when you sell and ship commercial software, shipped software can't look into the future. The real aspect of this issue, that I raised in my initial post, is that third party developers such as ourselves internally reuse various support classes for multiple bundle products, so when the host loads our products this issue surfaces. And yes, this thread does belong on the objC list and will be moving it there (I didn't realize there was a objC list when I originally posted). Before starting a discussion on the obj-c list, you may want to read the following thread from the clang mailing list: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-November/012026.html It may contain good answers to your questions about obj-c namespaces. On Nov 9, 2011, at 12:08 AM, Karl Goiser wrote: I think there is another solution that doesn’t involve making the language more complicated: I would complain to the suppliers of the bundles with conflicting class names. They know they are delivering into an environment with a flat namespace. It is up to them to defend against this sort of problem. It’s their fault that this problem is occurring. Karl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/andrew.omeara%40soundspectrum.com This email sent to andrew.ome...@soundspectrum.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org This email sent to devli...@shadowlab.org -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On 9 Nov 2011, at 22:44, Andreas Grosam wrote: On Nov 9, 2011, at 12:11 PM, Karl Goiser wrote: Your first option looks better to me! :-) All I’m saying is that Objective C is a very mature language now Depending on your perspective, you can say this for many languages. But only the dead ones do not evolve (Objective-C, does it, though) and if it has been able to get by You should ask the *developers*, not the *language*, if they experience issues and if they feel comfortable to workaround these issues. without adding this extra layer of complexity, why introduce it for an edge case to address a situation where people are expecting it to act like C++? I wouldn't say it is an edge case. If you develop small applications in a one-man company, and no plugins, you may feel this as a minor issue. Others won't agree, and actually have a big problem. Namespaces for Objective-C will likely not require the same feature set than what is available in C++ (e.g., no argument dependent lookup). There is also no need to do this. The only thing that should be considered when introducing namespaces in my opinion is, that it should be seamlessly integrated into Objective-C++. The negative asset against C++ made from a few posters here, is futile - Objective-C will have and be Objective-C++ as well. This requires to consider C++ syntax - and IMHO, regarding namespaces, it isn't ugly at all. Well, a lot of folk consider that Windows isn't ugly, after all they find it useful to do some work. But it is ugly! Let's forget the subjective term ugly. Why is it not good? The same reasoning is like the goto argument. Dijkstra pointed out gotos considered harmful, and Knuth said you could do structured programming with gotos. Both were correct. The problem with C is that it exposes too much low-level stuff that makes code inflexible and doesn't add anything to the power of the language. For example C pointers are the data structure equivalent of gotos. That is coming from the bottom up, so that stuff that is at a lower level than should be in an algorithmic language is exposed. The problem with C++'s namespace mechanism, is it's exposing the opposite, the higher-level organizational aspects, and putting these in the programming language. Thus the higher level that should also not be in a programming language is exposed. This complicates the programming activity and hides the true purpose of a computation. This is a concern. A parallel with aspect-oriented programming is that AOP attempts to remove cross-cutting concerns from regular code, so that the real purpose of a computation is clear. Modularization aspects (at least the mixing of modules) really should not be a part of the language. We program a module, but it should be as independent from its environment as possible. That is essential to reuse. Imports and #includes expose the environment internally in a module. We are progressing towards this and C++'s implementation of namespaces really goes in the opposite direction. It's the old I have a hammer so everything looks like a nail, but in C++'s case it's I have a programming language, so everything gets put in that. We really need to get away from that kind of thinking about programming languages and get back towards the Smalltalk ideal. Objective-C does that, which makes it the nicest flavour of C. The programming community needs to learn what the phrase 'separation of concerns' really means. Apple, after all is all about being simple and clean, and its language of choice should reflect that because, after all, it’s the developers who create the simple and clean. In my opinion, Objective C is an embodiment of the Apple attitude. From the developers view, using namespaces shouldn't appear to be complex and its usage should be certainly optional. IMHO, Objective-C could stay without having namespaces. C is required to use the same approach to avoid name conflicts: prefixes. However, introducing namespaces to Objective-C++ could be worthwhile to investigate if this is feasable. IFF, then integrating namespaces with C++ possibly could be done seamlessly. Andreas My favourite saying of all time is, “to a person with a hammer, everything looks like a nail.” Objective C is a screw, and you use a screwdriver on it, nor a hammer. As far as versioning issues from the same class in two bundles is concerned, if the class works to spec, there’s no problem. If it doesn’t, that’s a bug, and wouldn’t the bundles have to be updated anyway? Karl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com This email sent to
ObjC's flat and all-exported namespace, help!
Hello, Question for the cocoa experts here. I've googled around to no avail and lists.apple.com has been down for days(!).As ya'll know, when an app loads multiple bundles, the loader loads all the objC class name identifiers into a flat namespace, so ya can get that warning Class ___ is implemented in both foo.bundle and bar.bundle. One of the two will be used. Which one is undefined. This issue shows up a lot, especially to us third party developers that have common objC utility/support classes that appear in multiple bundle-based products. So the question of course is there any way to mark an entire objC class as being private (non-exported) to a bundle? I'm half shocked and half amazed that there seems to be no such way, in contrast to the compiler setting that C/C++ symbols can be set to be private by default. I feel like a radar really should be filed on this, or am I grossly missing something? That is, how can it be a good idea when things like the the OS X screensaver subsystem (or any app that uses 3rd party bundles) will inevitably have problems when two independent developers have two classes with the same name. And if you discount that case, then perhaps our case is more relevant, where as a third party that does author multiple bundles that are often plugins that get loaded side by side, causing this issue to surface. Yes, I know that one workaround is to mangle all objC class names based on something unique in the project (we are forced to do this with our screensaver products). I'd be more accepting of this if Xcode facilitated this (with perhaps a macro of or the introduction of @privateinterface or something), but I don't fancy the idea of having to stick nasty and limiting #includes, #defines, or #ifdefs all over our code to make sure stuff compiles and links correctly just to workaround the fact that objC seems like it should really allow classes to not be exported by default into a single/shared namespace. I suppose if there's no solution to this, then someone is going to describe how it can't be done because it would somehow break the loading of bundles. Well if that's the case, then I'm thinking that a radar is still worth filing because I'd be pretty surprised if the senior engineering level is going to agree that this whole flat objC namespace business is consistent with the precept that software should 'just work', rather than 'usually work' and emit user-attention-getting log messages as long as two internally private class names don't happen to have the same name. Thanks! Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On Nov 8, 2011, at 9:57 AM, Andy O'Meara andrew.ome...@soundspectrum.com wrote: So the question of course is there any way to mark an entire objC class as being private (non-exported) to a bundle? I'm half shocked and half amazed that there seems to be no such way, in contrast to the compiler setting that C/C++ symbols can be set to be private by default. I feel like a radar really should be filed on this, or am I grossly missing something? Yes, you are missing a fundamental difference between Objective-C and C++. There is one runtime for the entire application. Class definitions are loaded and registered with the runtime. The class is not defined by its symbol, it is defined by its named registration with the runtime. That is, how can it be a good idea when things like the the OS X screensaver subsystem (or any app that uses 3rd party bundles) will inevitably have problems when two independent developers have two classes with the same name. And if you discount that case, then perhaps our case is more relevant, where as a third party that does author multiple bundles that are often plugins that get loaded side by side, causing this issue to surface. I agree that it would be nice to have namespaces for classes. However, that is not how the language is designed right now. You should file a radar asking for such support. I suppose if there's no solution to this, then someone is going to describe how it can't be done because it would somehow break the loading of bundles. Well if that's the case, then I'm thinking that a radar is still worth filing because I'd be pretty surprised if the senior engineering level is going to agree that this whole flat objC namespace business is consistent with the precept that software should 'just work', rather than 'usually work' and emit user-attention-getting log messages as long as two internally private class names don't happen to have the same name. It can't be done now, but that doesn't mean it can't be done in the future. It all starts with filing bugs (and maybe a backwards-compatible proof of concept). --Kyle Sluder___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On Nov 8, 2011, at 9:57 AM, Andy O'Meara wrote: Yes, I know that one workaround is to mangle all objC class names based on something unique in the project (we are forced to do this with our screensaver products). I'd be more accepting of this if Xcode facilitated this (with perhaps a macro of or the introduction of @privateinterface or something), but I don't fancy the idea of having to stick nasty and limiting #includes, #defines, or #ifdefs all over our code to make sure stuff compiles and links correctly just to workaround the fact that objC seems like it should really allow classes to not be exported by default into a single/shared namespace. This is the only solution. I suppose if there's no solution to this, then someone is going to describe how it can't be done because it would somehow break the loading of bundles. Well if that's the case, then I'm thinking that a radar is still worth filing because I'd be pretty surprised if the senior engineering level is going to agree that this whole flat objC namespace business is consistent with the precept that software should 'just work', rather than 'usually work' and emit user-attention-getting log messages as long as two internally private class names don't happen to have the same name. rdar://problem/2821039 ER: Objective-C namespaces If you're familiar with Radar numbers, you'll recognize that the bug is very old. The name is a bit misleading - C++ namespaces or Java packages are little better than adding name prefixes by hand. (For example, they don't solve the problem of two developers importing the same static archive.) A real solution for class name collisions needs to be (1) automatic or nearly so, (2) predictable so nib references work, and (3) not incompatible with existing classes. It's a hard problem. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
So the question of course is there any way to mark an entire objC class as being private (non-exported) to a bundle? I'm half shocked and half amazed that there seems to be no such way, in contrast to the compiler setting that C/C++ symbols can be set to be private by default. I feel like a radar really should be filed on this, or am I grossly missing something? Yes, you are missing a fundamental difference between Objective-C and C++. There is one runtime for the entire application. Class definitions are loaded and registered with the runtime. The class is not defined by its symbol, it is defined by its named registration with the runtime. Well, I would suggest that that's not a fundamental difference. That's the objC bundle loader not having a markup/tag mechanism for omitting objC classes that the bundle author simply does not wish to be public. But I do agree that a fresh radar is in order. The workaround I went with is a class name mangler macro that all our classes now use, sigh. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
On 9 Nov 2011, at 05:21, Greg Parker wrote: On Nov 8, 2011, at 9:57 AM, Andy O'Meara wrote: Yes, I know that one workaround is to mangle all objC class names based on something unique in the project (we are forced to do this with our screensaver products). I'd be more accepting of this if Xcode facilitated this (with perhaps a macro of or the introduction of @privateinterface or something), but I don't fancy the idea of having to stick nasty and limiting #includes, #defines, or #ifdefs all over our code to make sure stuff compiles and links correctly just to workaround the fact that objC seems like it should really allow classes to not be exported by default into a single/shared namespace. This is the only solution. I suppose if there's no solution to this, then someone is going to describe how it can't be done because it would somehow break the loading of bundles. Well if that's the case, then I'm thinking that a radar is still worth filing because I'd be pretty surprised if the senior engineering level is going to agree that this whole flat objC namespace business is consistent with the precept that software should 'just work', rather than 'usually work' and emit user-attention-getting log messages as long as two internally private class names don't happen to have the same name. rdar://problem/2821039 ER: Objective-C namespaces If you're familiar with Radar numbers, you'll recognize that the bug is very old. The name is a bit misleading - C++ namespaces or Java packages are little better than adding name prefixes by hand. (For example, they don't solve the problem of two developers importing the same static archive.) A real solution for class name collisions needs to be (1) automatic or nearly so, (2) predictable so nib references work, and (3) not incompatible with existing classes. It's a hard problem. I agree, in NS::class, just substitute the ugly :: with _ and you see it's just a trick: NS_class. There should be a decent solution that doesn't need to put extra bookkeeping constructs in the language, and so that the clash is avoided in one place. Another point is that code in a class should not be bound to the environment and the C++ and Java way of doing it says 'environment' all over the place. A different approach is in Eiffel that identifies the problem as being when you try to use two libraries together and handles clashes in one place by renaming (in a configuration file separate from code). Thus it becomes a linker concern. Language design should keep compilation concerns separate from linking concerns (and indeed not just static linking, but dynamic run-time linking). On the other hand most Unix style C linkers really don't do enough to make sure things can be sensibly linked together, so the basic languages and compilers get bent instead and then programmers are forced to think of all these things at a lower level than they should need to. Similarly, imports and #includes are really bad, because they couple modules to their environment, rather than this kind of linkage being done externally in one place and handled by the linker. This means that if any import changes, you have to go through all the files and change all the imports and it looks like you are programming, but really you are not. So we invent a refactoring to take care of something that shouldn't exist. Anyway, that's my argument for not doing namespaces in Objective-C the Java or C++ way. There's not so much clutter in Java, but there is so much clutter in C++ it looks like Windows! I'm sure Apple will come up with a better solution and things they have done over the last few years with Objective-C (and tagged pointers in Lion as we have just discussed in the Obj-C group) have been very nice and simplifying (even for a language based on C). We should not force them into doing anything the same bad old way that everything else does. Ian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
Le 9 nov. 2011 à 01:37, Ian Joyner a écrit : On 9 Nov 2011, at 05:21, Greg Parker wrote: On Nov 8, 2011, at 9:57 AM, Andy O'Meara wrote: Yes, I know that one workaround is to mangle all objC class names based on something unique in the project (we are forced to do this with our screensaver products). I'd be more accepting of this if Xcode facilitated this (with perhaps a macro of or the introduction of @privateinterface or something), but I don't fancy the idea of having to stick nasty and limiting #includes, #defines, or #ifdefs all over our code to make sure stuff compiles and links correctly just to workaround the fact that objC seems like it should really allow classes to not be exported by default into a single/shared namespace. This is the only solution. I suppose if there's no solution to this, then someone is going to describe how it can't be done because it would somehow break the loading of bundles. Well if that's the case, then I'm thinking that a radar is still worth filing because I'd be pretty surprised if the senior engineering level is going to agree that this whole flat objC namespace business is consistent with the precept that software should 'just work', rather than 'usually work' and emit user-attention-getting log messages as long as two internally private class names don't happen to have the same name. rdar://problem/2821039 ER: Objective-C namespaces If you're familiar with Radar numbers, you'll recognize that the bug is very old. The name is a bit misleading - C++ namespaces or Java packages are little better than adding name prefixes by hand. (For example, they don't solve the problem of two developers importing the same static archive.) A real solution for class name collisions needs to be (1) automatic or nearly so, (2) predictable so nib references work, and (3) not incompatible with existing classes. It's a hard problem. I agree, in NS::class, just substitute the ugly :: with _ and you see it's just a trick: NS_class. There should be a decent solution that doesn't need to put extra bookkeeping constructs in the language, and so that the clash is avoided in one place. Another point is that code in a class should not be bound to the environment and the C++ and Java way of doing it says 'environment' all over the place. A different approach is in Eiffel that identifies the problem as being when you try to use two libraries together and handles clashes in one place by renaming (in a configuration file separate from code). Thus it becomes a linker concern. Objective-C uses a dynamic runtime. The linkers (both the static one and the dynamic one) cannot take care of all possible cases. How do you handle NSClassFromString used with a non constant string ? Language design should keep compilation concerns separate from linking concerns (and indeed not just static linking, but dynamic run-time linking). On the other hand most Unix style C linkers really don't do enough to make sure things can be sensibly linked together, so the basic languages and compilers get bent instead and then programmers are forced to think of all these things at a lower level than they should need to. Similarly, imports and #includes are really bad, because they couple modules to their environment, rather than this kind of linkage being done externally in one place and handled by the linker. This means that if any import changes, you have to go through all the files and change all the imports and it looks like you are programming, but really you are not. So we invent a refactoring to take care of something that shouldn't exist. Anyway, that's my argument for not doing namespaces in Objective-C the Java or C++ way. There's not so much clutter in Java, but there is so much clutter in C++ it looks like Windows! I'm sure Apple will come up with a better solution and things they have done over the last few years with Objective-C (and tagged pointers in Lion as we have just discussed in the Obj-C group) have been very nice and simplifying (even for a language based on C). We should not force them into doing anything the same bad old way that everything else does. -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
This should be on the Obj-C list. This whole discussion is about the language implementation. The Obj-C list needs more love anyway. On Nov 9, 2011, at 10:30 AM, Jean-Daniel Dupas wrote: Le 9 nov. 2011 à 01:37, Ian Joyner a écrit : On 9 Nov 2011, at 05:21, Greg Parker wrote: On Nov 8, 2011, at 9:57 AM, Andy O'Meara wrote: Yes, I know that one workaround is to mangle all objC class names based on something unique in the project (we are forced to do this with our screensaver products). I'd be more accepting of this if Xcode facilitated this (with perhaps a macro of or the introduction of @privateinterface or something), but I don't fancy the idea of having to stick nasty and limiting #includes, #defines, or #ifdefs all over our code to make sure stuff compiles and links correctly just to workaround the fact that objC seems like it should really allow classes to not be exported by default into a single/shared namespace. This is the only solution. I suppose if there's no solution to this, then someone is going to describe how it can't be done because it would somehow break the loading of bundles. Well if that's the case, then I'm thinking that a radar is still worth filing because I'd be pretty surprised if the senior engineering level is going to agree that this whole flat objC namespace business is consistent with the precept that software should 'just work', rather than 'usually work' and emit user-attention-getting log messages as long as two internally private class names don't happen to have the same name. rdar://problem/2821039 ER: Objective-C namespaces If you're familiar with Radar numbers, you'll recognize that the bug is very old. The name is a bit misleading - C++ namespaces or Java packages are little better than adding name prefixes by hand. (For example, they don't solve the problem of two developers importing the same static archive.) A real solution for class name collisions needs to be (1) automatic or nearly so, (2) predictable so nib references work, and (3) not incompatible with existing classes. It's a hard problem. I agree, in NS::class, just substitute the ugly :: with _ and you see it's just a trick: NS_class. There should be a decent solution that doesn't need to put extra bookkeeping constructs in the language, and so that the clash is avoided in one place. Another point is that code in a class should not be bound to the environment and the C++ and Java way of doing it says 'environment' all over the place. A different approach is in Eiffel that identifies the problem as being when you try to use two libraries together and handles clashes in one place by renaming (in a configuration file separate from code). Thus it becomes a linker concern. Objective-C uses a dynamic runtime. The linkers (both the static one and the dynamic one) cannot take care of all possible cases. How do you handle NSClassFromString used with a non constant string ? Language design should keep compilation concerns separate from linking concerns (and indeed not just static linking, but dynamic run-time linking). On the other hand most Unix style C linkers really don't do enough to make sure things can be sensibly linked together, so the basic languages and compilers get bent instead and then programmers are forced to think of all these things at a lower level than they should need to. Similarly, imports and #includes are really bad, because they couple modules to their environment, rather than this kind of linkage being done externally in one place and handled by the linker. This means that if any import changes, you have to go through all the files and change all the imports and it looks like you are programming, but really you are not. So we invent a refactoring to take care of something that shouldn't exist. Anyway, that's my argument for not doing namespaces in Objective-C the Java or C++ way. There's not so much clutter in Java, but there is so much clutter in C++ it looks like Windows! I'm sure Apple will come up with a better solution and things they have done over the last few years with Objective-C (and tagged pointers in Lion as we have just discussed in the Obj-C group) have been very nice and simplifying (even for a language based on C). We should not force them into doing anything the same bad old way that everything else does. -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ObjC's flat and all-exported namespace, help!
I think there is another solution that doesn’t involve making the language more complicated: I would complain to the suppliers of the bundles with conflicting class names. They know they are delivering into an environment with a flat namespace. It is up to them to defend against this sort of problem. It’s their fault that this problem is occurring. Karl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
