A method consists of five different aspects: arguments, variables, ColdC code, access, and flags. Arguments, variables, and ColdC code are all defined within the method code. Access and flags are set and changed outside the method definition. Arguments define how the method can be called. Variables define any local variables used in the method. Code consists of the rest of the method instructions. Access defines how the method may be called and flags define any other functionality and behavior of the method.
Code
Arguments, local variables, and the ColdC code for a method are defined all at once, within one block of text formatted as:
arg arg1, arg2, ..., argN;
var var1, var2, ..., varN;
statement1;
statement2;
...
statementN;
The first line is the argument declaration. The second line is the local variable declaration. Any remaining lines are standard ColdC statements, also known generically as ColdC code.
The arg declaration gives a list of argument variables whose values will correspond to the arguments passed to the method. The arg declaration may be omitted if the method does not take any arguments. If the final argument variable is preceeded with the splice operator (@), then the method can accept any number of argments and the variable in question will be a list of the remaining arguments. If the final argument is not defined in this way, the method can only accept the defined number of arguments and sending any more will cause a ~numargs error to be thrown.
The var declaration is used to define local variables. Any variable given in the list will exist during the execution of the method. In the case of conflicts with object variables, the local variable is used first. The var declaration may be omitted if no local variables are declared.
Once the method begins normal execution, both arguments and local variables are treated the same (as local variables). The statements (statement1, statement2, etc.) compose the ColdC code body.
A method is defined using the ColdC function add_method(), or within a textdump.
Flags
Method flags define certain behavior features of the method. Currently the following method flags exist:
| nooverride | Methods which are flagged nooverride cannot be overridden by any of the defining object's descendants. |
| locked | This flag locks all aspects of a method. Locked methods cannot have their access or flags changed, nor can they be recompiled during runtime. Locked methods can be changed outside of the regular running environment (such as in a textdump or with coldcc). NOTE: This flag is not currently available to methods written and used in The Dreaming City's DreamCore. |
| forked | This flag is used to specify that the method forks from the current task. The return value of a forked method is the task id of the new task. |
| native | This specifies a native method. Native methods are not really methods, but are actually functions acting as methods. Because of this, native methods cannot be listed or manipulated in most of the usual ways. |
All method flags, with the exception of native, can be manipulated using the functions method_flags() and set_method_flags().
Access
It is possible to restrict calls to a method by setting the method's access. By default all methods are public methods. The available settings for method access are:
| public | This access state is the default. A public method can be called by any object. |
| protected | Protected methods can only be called by the defining object and descendants of the defining object (sender() must be this()). |
| private | Private methods can only be called by the object they were defined on (caller() must be this()). |
| root | Root methods can only be called by $root (caller() must be $root). |
| driver | Driver methods can only be called by the driver. |
| frob | This access state only allows frobbed method calls. |
Method access can be manipulated using the functions method_access() and set_method_access().
Frobbed Methods
Frobbed method calls behave slightly different than any other access restriction. First, a frobbed method may only be called from a frob. That is, it must be called where the frob is the receiver, such as:
(<$my_object, #[]>).my_method()
If it is called in the normal way, it will be as if the frobbed method does not exist. For example, assume $obj_a is a parent of $obj_b. $obj_a defines the method .name() as a standard method, but $obj_b overrides it and defines it as a frobbed method. Calling $obj_b.name() will actually skip the frobbed method and execute the method defined on $obj_a. Calling (<$obj_b, #[]>).name() will execute the frobbed method defined on $obj_b.
When a frobbed method passes back to an overridden method it will look first for another frobbed method, and then for a standard method.
If a method is defined as non-overrideable, it may still be overridden by a frobbed method. This allows for frob class objects to emulate real object systems in the database, with frobs.
