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
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
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
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
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
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
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
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
.. 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
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…
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…
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++?
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)
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
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
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
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
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
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
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
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
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
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,
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
24 matches
Mail list logo
