AAL Object Representation

How to build AAL Objects.

Content of this chapter:

   Open Questions
     Diverent callings
       Weak calling
       AAL internal calls
         virtual calls
         non-virtual calls
       AAL to C++ ACDK calls
     virtual calls for derived Objects
   Basics
     ClazzInfo
     DMI
   Elements
     Units
     Functions
   Binding
     Static Binding
     Dynamic Binding
     Discussion
     Implementation

!	This page is outdated.

Open Questions

Diverent callings

At compile time it should be branch between different calling conventions.

Weak calling

Resolution at runtime. Callee interpret the arguments. Standard DMI.

Virtual calls must be dispatched. One way is to use DMI mechanism, which is probably not the fasted way. Alternativelly AalObjects provides a vtable, which makes it necesarry to manage a hash table for each method entry.

non-virtual calls

non-virtual callers can remember ClazzMethodInfo after the first call and call it directly.

AAL to C++ ACDK calls

virtual calls for derived Objects

ACDK DMI doesn't support currently the non-virtual call flag. This may be necessary.

Basics

ClazzInfo

ClazzInfo for internal AAL Objects. The class DClazzInfo is a dynamic compatible version of ClazzInfo.

DMI

Using ACDK DMI interface also for internal AAL Objects. Overload the standard implementation functions of DMI.

Elements

Units

Problem: In the current definituion of ClazzInfo, there is no possibility to have nested ClazzInfo. On the other side, Units are just wrapper to namespaces and cannot contain functions, members and so on. Originally the idea to resolve componed type names was to recursivally resolve names.

acdk.lang.Object o = new acdk.lang.Object();
// whould be resolved
globlal.getType("acdk").getType("lang").getType("Object");

Alternativally (actually the way it is implemented) a compositive name will be resolved at ones: global.getType("acdk/lang/Object")

Functions

Function may be also a ACDK Object, which have a standard method 'call'.

Binding

Calling methods can have static or dynamic binding.

Static Binding

On static binding at compile time the signature of the called function is known. The mapping of the parameters (default parameter, named parameter, pass attributes (in, out) rest paramters) will be done at compile time. The polymorphic function will be resolved (The Code holds a ClazzMethodInfo). The caller pushes all parameter on the stack and calls the function.

Dynamic Binding

If the called type is unknown, a dynamic call will be invoked. Instead of just pushing the parameters on the stack, a invocation frame has to be build on the stack, which describes the parameters:

Number of unnamed parameters.
pass attributes of each parameter.
Number of named parameters.
Name of parameter, Value of parameter.

If used external Classes, for which no Metainfo at compile time is available, dynamic binding is the only solution.

Discussion

Whenever possible, static binding should be prefered, because of performance. Another important issue is the support of extended argument attributes like in, out. By default the value (or the value of the reference of an Object) will be pushed onto the stack before invoking the function. This will not work with out parameters. Alternativally each argument has to be casted by the caller:

void foo(out int i) { i = 42; }

int i;
foo(outOf i);

Static binding has no dynamic resolution of polymorphic functions:

void foo(Object o);
void foo(String o);
Object o = new String("asdf");
foo(o); // will call foo(Object o) on static binding
// will call foo(String o) on dynamic binding

Implementation

A problem for static binding is to figure out the formal type of the arguments at compile time:

void foo(String s);
void foo(int i);
String s = new String("asdf");
foo(s + 2);
// what is the formal type of 's + 2'?
foo(Integer.parseInt("1")); // same question

The postParse step has to resolve the types of an expression. Static binding will be implemented later and will be available via an unit attribute similar to the Perl strict statement. In case of NamedArguments the static binding resolves the named arguments into the order of the normal argument position. The dynamic binding has to pass the named arguments to the invoke interface.