• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: object instance names generated on the fly?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: object instance names generated on the fly?


  • Subject: Re: object instance names generated on the fly?
  • From: Sherm Pendley <email@hidden>
  • Date: Sat, 22 Mar 2003 12:13:33 -0500

On Saturday, March 22, 2003, at 11:20 AM, Marcel Weiher wrote:

But that's just simulating an array (in a very roundabout way). Just use an NSArray.

That depends on your perspective. It's equally valid to say that using NSDictionary to store arbitrarily-named objects is just simulating a dynamic name space in a roundabout way. ;-)

I'm not convinced that Ben needs a dynamic name space, but there *are* occasions where such would be useful. For example, I maintain a language bridge, and I'd like to be able to export named constants and enums to the guest language. These change with each version of OS X, so the ideal solution would be to sniff around the name space, and export whatever variables I find by their correct names.

Unfortunately, Objective-C's name space, like C's, is statically defined at compile time, so I can't do that with variables. I have to compile a separate version of the constants module for each version of OS X, and decide at runtime which one to load. It's klunky, and failure-prone.

It would be nice if the Objective-C runtime were as flexible with variables as it is with class definitions. My bridge queries the runtime to get a list of all registered classes, so all Objective-C classes are available for use in the guest language. The opposite is also true, as the runtime allows class definitions to be added and/or extended dynamically.

I'm starting to look into the Mach-O stuff to dig around exported symbol tables; fortunately I only need to see what's already there, not add new symbols, so that may be good enough. It's a good bit harder than it needs to be, though. ;-(

By the way, Perl's name spaces *are* just using hashes - dictionaries, in Cocoa-speak. There's just a layer of syntax sugar over them, so that you don't have to deal with them directly unless you want to. For example, the following code snippets produce identical results:

# Snip 1
# Change the default package, and use the variable name alone
package Foo;
$Bar = 1;

# Snip 2
# Use the fully-qualified variable name
$Foo::Bar = 1;

# Snip 3
# Build up the fully-qualified variable name dynamically
$myPackage = "Foo";
$myVar = "Bar";
${$myPackage . '::' . $myVar} = 1;

# Snip 4
# Get a handle on the package hash, and treat the variable name as
# a key in that hash
%myPackage = %Foo::;
$myPackage{'Bar'} = 1;

sherm--
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: object instance names generated on the fly? (From: Marcel Weiher <email@hidden>)

  • Prev by Date: Custom NSLayoutManager for NSTextView
  • Next by Date: NSImage not using NSImageRep when drawing to NSPSAndPDFGraphicsContext
  • Previous by thread: Re: object instance names generated on the fly?
  • Next by thread: Re: object instance names generated on the fly?
  • Index(es):
    • Date
    • Thread