Why yes I do have experience with event-driven programming. And I agree, event-drive computing takes some getting use. You are either in a STATE of Wait-for-event-to-occur OR a STATE where an event has occurred and the event-handler has moved program execution to the appropriate code.
For this discussion thread that I started, I am focused on the "designs" of how Objects communicate. Well, that's a simple thought, objects are sent messages and the syntax is
return-value-if-any = [Pointer-to-target-object Method-to-Run:with-any-parameters];
that's how they communicate.
The problem is knowing the "Pointer-to-target-object" if the target-object was made "new", or instantiated in a scope the current program execution isn't operating in. I thought there might be a Framework device or an Objective-C feature to resolve this problem, apparently there is not.
Apple has a doc deep in their references titled "Object-Oriented Programming with Objective-C" in the Section "Structuring Programs" there is discussion on the topics of "Outlet Connections" and "Activating the Object Network".
Here is the root paragraph of this discussion thread.
SO. . . is there a "design" for "a service that identifies objects by name"?
Here's the complete section of that document:
https://developer.apple.com/library...s.html#//apple_ref/doc/uid/TP40005149-CH4-SW2
The "problem" you perceive doesn't exist. The section you cited is talking about how objects make connections to one another. It specifically discusses intrinsic and extrinsic connections. For an intrinsic connection, the object is usually made by its enclosing object, when the enclosing object needs to do so. Specifically, you write code to call the alloc method of the class, then the init method of the object. You do this for every intrinsic object that the enclosing object needs. There is no unresolved problem here; objects make other objects when they need to.
For extrinsic connections, getting the "other object" depends entirely on the design of the program. There isn't a universal way to do this, because different programs need different things. The example in the above link is an Appliance object with a connection to a Valve object. One approach is a vendor method (a type of
Factory Method) that returns existing Valve objects it knows about. How would the Valve vendor know what Valves to vend (return)? It's presumably designed to know that, as part of what the programmer wrote it to do. In other words, it solves the problem of knowing what Valves to vend, independent of any Appliance object that might request those Valves.
An example of a kind of "factory method" in procedural programming is the stdio function fopen(). You pass it the name of a file, how you want to access the data in the file, and it "vends" or returns a "file-stream object" of type FILE*. You then work with that file-stream object, and not with the filename.
How does the caller of fopen() know what filename to pass in, or what access to request? The programmer writes it to do what the programmer wants done. If the filename is builtin, then it's builtin. If it's a command-line arg, then it's a command-line arg. If it's a string received from a network connection, then it's a string from a network connection. The programmer decides what's appropriate, depending on what the program itself is intended to do. If you don't know the intent, or what the program should do, how could you write code to express that intent to the machine?
You seem to be looking for a universal way to attach names to objects, so they can be retrieved by any other object. There is no such solution. You're reading too much into what the cited paragraph says. It's discussing theoreticals or hypotheticals, in order to illustrate the use of terms like "intrinsic" or "extrinsic" or "outlet". There are no actual Cocoa classes for Valve, Appliance, Building, or Pipe, nor is there a dispenser of arbitrary named objects.
One specific way that names can be attached to objects is with a global variable holding an NSMutableDictionary. However, objects would have to explicitly be added to this NSMutableDictionary (registration), or explicitly removed. There won't be some magical process whereby every object created will be added to this dictionary along with some generated name. If you don't write code to do this, it won't happen. And unless there's a reason for the program to do this, I don't see why you'd write code to do it.
To summarize:
The perceived problem doesn't exist. It's a red herring. There are two distinct cases:
- An object directly makes other objects it needs, in which case it has the object pointers because it just made them. It already knows the class, because the programmer writing the code knows which class to instantiate. Hence, there is no problem.
- It calls on another object it already knows to supply objects it needs. That other object will return suitable object pointers, which it obtains by applying either #1 or #2. Since the caller receives object pointers from the vending object, there is again no problem.
One approach to #2 is to have a class with a class method that returns objects. Then the caller needs to know the class-name, but the programmer will already know that, so imparting that knowledge to the caller means writing code that calls the class's method, as distinct from calling the class's alloc method.
NSString *), or any other key type. But you'd want to make sure that the objects were weakly referenced so this didn't become a massive memory leak.