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
