AAL Object Representation
| Intentional Programming | ACI Concept | AAL definition | AAL syntax | AAL parser | Object Representation | OpCode | Reference Links |
How to build AAL Objects.
Open Questions! | 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.
AAL internal calls
virtual calls
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"); |
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.
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 |