Discussion

In general, names need not be unique, are not automatically assigned, and leaving the name as nil is acceptable.

Some subclasses are designed so that their instances can be cached. For instances of those subclasses, the name is required, and must be unique.

Discussion

This property is used by the deriveNameFrom: method.

This implementation simply raises an assertion exception. Each concrete subclass should override this property to return a useful identifiable name suffix. A subclass can return nil from this property to indicate that automatic naming should not be performed.

Discussion

This method simply returns YES by default, and in most cases this is sufficient. However, for some structural subclasses (notably subclasses of CC3Node) it may be desirable to not copy some components.

This property is not universally automatically applied or honoured. It is up to the invoker and invokee to agree on when to make use of this property.

Discussion

You can use this property to add any additional information you want to an instance of CC3Identifiable or its concrete subclasses (CC3Node, CC3Mesh, CC3Material, CC3Texture, etc.).

If you have non-object data to attach, such as a structure, or a pointer to data in a memory space (perhaps loaded from a file), you can wrap it in an instance of NSData and attach it here.

To assist in managing this data, the methods initUserData is invoked automatically during the initialization and deallocation of each instance of this class. You can override this method by subclassing, or by adding extention categories to the concrete subclasses of CC3Identifiable, (CC3Node, CC3Mesh, CC3Material, CC3Texture, etc.), to create or retrieve the data, and attach it to the new instance.

When copying instances of CC3Identifiable and its subclasses, the copyUserDataFrom: method is invoked in the new copy so that it can copy the data from the original instance to the new instance copy.

In this abstract class, the copyUserDataFrom: method simply sets the userData property of the copy to the object returned from the same property in the original instance, without creating a copy of the userData object. If you need the userData object to be copied as well, you can override the copyUserDataFrom: method by subclassing, or by adding extention categories to the concrete subclasses of CC3Identifiable, (CC3Node, CC3Mesh, CC3Material, CC3Texture, etc.), to copy the userData object and assign it to the new instance.

Discussion

The returned instance is retained. It is the responsiblity of the caller to manage the lifecycle of the returned instance and perform the corresponding invocation of the release method at the appropriate time.

This copy operation is a deep copy. Copies of most of the content of the original will be created as well. For structural subclasses, such as CC3Node, copies will be made of each structual element (eg- child nodes). Some exceptions are made. For instance, copies are generally not made for fixed, voluminous content such as mesh data. In addition, subclasses may excuse themselves from being copied through the shouldIncludeInDeepCopy property.

This copy operation is a deep copy. Copies of most of the content of the original will be created as well. For structural subclasses, such as CC3Node, copies will be made of each structual element (eg- child nodes). Some exceptions are made. For instance, copies are generally not made for fixed, voluminous content such as mesh data. In addition, subclasses may excuse themselves from being copied through the shouldIncludeInDeepCopy property.

The copy… methods may often be used to duplicate an instance many times, to create large number of similar instances to populate a game. To help you verify that you are correctly releasing and deallocating all these copies, you can use the instanceCount class method to get a current count of the total number of instances of all subclasses of CC3Identifiable,

Subclasses that extend copying should not override this method, but should override the populateFrom: method instead.

Discussion

Care should be taken when choosing the class to be instantiated. If the class is different than that of this instance, the populateFrom: method of that class must be compatible with the contents of this instance.

The returned instance is retained. It is the responsiblity of the caller to manage the lifecycle of the returned instance and perform the corresponding invocation of the release method at the appropriate time.

This copy operation is a deep copy. Copies of most of the content of the original will be created as well. For structural subclasses, such as CC3Node, copies will be made of each structual element (eg- child nodes). Some exceptions are made. For instance, copies are generally not made for fixed, voluminous content such as mesh data. In addition, subclasses may excuse themselves from being copied through the shouldIncludeInDeepCopy property.

The copy… methods may often be used to duplicate an instance many times, to create large number of similar instances to populate a game. To help you verify that you are correctly releasing and deallocating all these copies, you can use the instanceCount class method to get a current count of the total number of instances of all subclasses of CC3Identifiable,

Subclasses that extend copying should not override this method, but should override the populateFrom: method instead.

Discussion

In this abstract class, this method simply sets the userData property of this instance to the object returned from the same property in the specified original instance, without creating a copy of the userData object. If you need the userData object to be copied as well, you can override this method by subclassing, or by adding extention categories to the concrete subclasses of CC3Identifiable, (CC3Node, CC3Mesh, CC3Material, CC3Texture, etc.), to copy the userData object and assign it to the new instance.

Discussion

The returned instance is retained. It is the responsiblity of the caller to manage the lifecycle of the returned instance and perform the corresponding invocation of the release method at the appropriate time.

This copy operation is a deep copy. Copies of most of the content of the original will be created as well. For structural subclasses, such as CC3Node, copies will be made of each structual element (eg- child nodes). Some exceptions are made. For instance, copies are generally not made for fixed, voluminous content such as mesh data. In addition, subclasses may excuse themselves from being copied through the shouldIncludeInDeepCopy property.

The copy… methods may often be used to duplicate an instance many times, to create large number of similar instances to populate a game. To help you verify that you are correctly releasing and deallocating all these copies, you can use the instanceCount class method to get a current count of the total number of instances of all subclasses of CC3Identifiable,

Subclasses that extend copying should not override this method, but should override the populateFrom: method instead.

Discussion

Care should be taken when choosing the class to be instantiated. If the class is different than that of this instance, the populateFrom: method of that class must be compatible with the contents of this instance.

The returned instance is retained. It is the responsiblity of the caller to manage the lifecycle of the returned instance and perform the corresponding invocation of the release method at the appropriate time.

This copy operation is a deep copy. Copies of most of the content of the original will be created as well. For structural subclasses, such as CC3Node, copies will be made of each structual element (eg- child nodes). Some exceptions are made. For instance, copies are generally not made for fixed, voluminous content such as mesh data. In addition, subclasses may excuse themselves from being copied through the shouldIncludeInDeepCopy property.

The copy… methods may often be used to duplicate an instance many times, to create large number of similar instances to populate a game. To help you verify that you are correctly releasing and deallocating all these copies, you can use the instanceCount class method to get a current count of the total number of instances of all subclasses of CC3Identifiable,

Subclasses that extend copying should not override this method, but should override the populateFrom: method instead.

Discussion

The returned instance is retained. It is the responsiblity of the caller to manage the lifecycle of the returned instance and perform the corresponding invocation of the release method at the appropriate time.

This copy operation is a deep copy. Copies of most of the content of the original will be created as well. For structural subclasses, such as CC3Node, copies will be made of each structual element (eg- child nodes). Some exceptions are made. For instance, copies are generally not made for fixed, voluminous content such as mesh data. In addition, subclasses may excuse themselves from being copied through the shouldIncludeInDeepCopy property.

The copy… methods may often be used to duplicate an instance many times, to create large number of similar instances to populate a game. To help you verify that you are correctly releasing and deallocating all these copies, you can use the instanceCount class method to get a current count of the total number of instances of all subclasses of CC3Identifiable,

Subclasses that extend copying should not override this method, but should override the populateFrom: method instead.

Discussion

Care should be taken when choosing the class to be instantiated. If the class is different than that of this instance, the populateFrom: method of that class must be compatible with the contents of this instance.

The returned instance is retained. It is the responsiblity of the caller to manage the lifecycle of the returned instance and perform the corresponding invocation of the release method at the appropriate time.

This copy operation is a deep copy. Copies of most of the content of the original will be created as well. For structural subclasses, such as CC3Node, copies will be made of each structual element (eg- child nodes). Some exceptions are made. For instance, copies are generally not made for fixed, voluminous content such as mesh data. In addition, subclasses may excuse themselves from being copied through the shouldIncludeInDeepCopy property.

The copy… methods may often be used to duplicate an instance many times, to create large number of similar instances to populate a game. To help you verify that you are correctly releasing and deallocating all these copies, you can use the instanceCount class method to get a current count of the total number of instances of all subclasses of CC3Identifiable,

Subclasses that extend copying should not override this method, but should override the populateFrom: method instead.

Discussion

Typically, this is invoked when one CC3Identifiable is added as a component to another.

This implementation concatenates the value of the nameSuffix property of this instance onto the name of the specified CC3Identifiable, and sets that into the name property of this instance. If a subclass returns nil from the nameSuffix property, no name is generated.

Returns whether the name of this instance was changed.

Discussion

Typically, this is invoked when one CC3Identifiable is added as a component to another.

This implementation concatenates the value of the specified suffix onto the name of the specified CC3Identifiable, and sets that into the name property of this instance.

Returns whether the name of this instance was changed.

Discussion

This implementation simply invokes the description method. Subclasses with more substantial content can override to provide much more information.

Discussion

This implementation simply sets the userData property to nil. You can override this method in a subclass or by creating extension categories for the concrete subclasses, (CC3Node, CC3Mesh, CC3Material, CC3Texture, etc.), if the userData can be initialized and retained in a self-contained manner.

Alternately, you can leave this method unimplemented, and set the userData property from outside this instance.

Discussion

This method is invoked automatically during object copying via the copy or copyWithZone: method. In most situations, the application should use the copy method, and should never need to invoke this method directly.

Subclasses that add additional instance state (instance variables) should extend copying by overriding this method to copy that additional state. Superclass that override this method should be sure to invoke the superclass implementation to ensure that superclass state is copied as well.