ObjectMaker

File "Objects.Def"; line 60666 ### Error: can not handle reference numbers greater than 11500

I wanted to use larger value for my reference numbers. Is there any hope for me?

Unfortunately, this requires a change to ObjectMaker, so you're limited to values less than 11500 for your object reference numbers.

When should I declare operation numbers in my .Def files?

If you don't declare operation numbers then ObjectMaker will number them for you, and it will do so in the order that it finds them in your class definition files.

One reason it is better to explicitly assign these operation numbers is because operation numbers are almost always included in compiled magic scripts (in your Objects.Def file). If you let ObjectMaker assign operation numbers then every time you add, delete, or move an operation you will probably have to edit and re-dump all of the scripts in your package to keep them working properly.

Another reason to hard-code your operation numbers is to know the numbers so you call the operations from other packages.

Is it possible to split the instances in my Objects.Def file into more than one file?

Yes, it is. In the package makefile is a line that says:

instanceFiles = Objects.Def

Simply add any additional instance files to this list. The restriction is that the names of these additional files must end in Objects.Def (for example, SoundObjects.Def, ImageObjects.Def, etc.)

What is the keyword "global" used for?

The global keyword marks a field as a class global. This field is shared by all instances of a class. One example is the songPlaying field of MIDISong. This holds the currently playing song, if any. To access this global, you would write code like:

  return FieldOf(ClassGlobals(), MIDISongGlobals_songPlaying);

ClassGlobals() is a macro that uses CURRENTCLASS. MIDISongGlobals_songPlaying is similar to other field numbers, and is generated by ObjectMaker when it encounters the global keyword in your class definition file.

What determines the Created and Last Modified dates as shown in the package scene in the storeroom?

Packages have fields that hold the created and last modified dates. The dates in the package scene are a reflection of these values. The created date is filled in initially by ObjectMaker, when your package is built. The last modified date is the last time Magic Cap committed data into your package persistent cluster. (This update code also fills in the creation date if that field is zero for whatever reason.) Of course, these dates are only as accurate as the times of the machine you built your package on, and of the communicator running the package.

Yes, you can have holes, but they should not be large holes. For instance definitions in Objects.Def, ObjectMaker creates an ObjectList which contains all the object instances. The Inspector uses this list to translate an ObjectID into an instance reference number if it can. The index into the ObjectList is the instance reference number, so if you leave gaps in your numbers, youÍll wind up with a lot of blank entries in this list. If you specify the -small option for ObjectMaker, this reference list doesnÍt get generated, in which case it doesnÍt matter if you have gaps in your instance numbers.

For classes, operations, and attributes ObjectMaker creates a ClassList object that lists all your classes in order, an OperationList for your operations and attributes, and an InstrinsicList for your intrinsic operations. The class, operation, attribute or intrinsic number is used as an index into the appropriate list. If you leave gaps in the numbering, you will cause gaps to be left in these lists. ThereÍs no way to avoid these, so not leaving gaps in these numbers is more important than not leaving gaps in the instance numbers.

The noCopy keyword describes a weak relationship between two objects. Normally, when you copy or destroy an object, any objects directly referred to by that object are also copied or destroyed. (By directly referred to, I mean the reference is not through an indexical.) By specifying a field is noCopy, the object referenced in that field will not be copied or destroyed with the referencing object. We realize that noCopy isn't very descriptive. In future release of the class definition language (and the ObjectMaker tool which compiles class definitions), we'll use weak as the keyword to represent this relationship.

Be aware that when you copy an object with a noCopy field, the corresponding field in the newly created copy will reference the same object referenced by the field of the copied object:

Define Class SomeClass;
   inherits from Object;

   field field1: SomeClass, noCopy;
   field field2: SomeClass;
End Class;

Instance SomeClass object1;
   field1: (SomeClass object2);
   field2: (SomeClass object3);
End Instance;

Instance SomeClass object4;
   field1: (SomeClass object2);
   field2: (SomeClass object5);
End Instance;