When we did think of signal/slot signals, we finally gave up because we could
not find a suitable object syntax to represent this feature.

Here's my proposal : make methods in Nosica be real objects.
What this means ? Well, don't know yet where this is heading but here's the
syntax one can write :

In QT :
connect(obj1, SIGNAL(method1), obj2, SLOT(method2));

In Nosica :
obj1.method1.connect(obj2.method2);

Nice isn't it ?

A method is an object.
That means we must provide a way to "browse" a method.
Like in :
Method m = obj1.method1;

class Method /* extends Object */
{
// browsing method
public bool isSub();
public ResultType getResultType();
public string getName();
public bool isConst();
public MethodKind getKind();
public Iterator<Argument> iterateArguments();

// signal / slot / connection
public void connect(Method m);
public void disconnect(Method m);
}

class Argument
{
public bool isConst();
public TypeName getTypeName();
}

class ResultType extends Argument
{
public bool isSub();
}

class MethodKindEnum
{
public static MethodKindEnum infix = new MethodKindEnum(0);
public static MethodKindEnum postfix = new MethodKindEnum(1);
public static MethodKindEnum prefix = new MethodKindEnum(2);
public static MethodKindEnum constructor = new MethodKindEnum(3);
public static MethodKindEnum destructor = new MethodKindEnum(4);
public static MethodKindEnum property = new MethodKindEnum(5);
public static MethodKindEnum propertyArray = new MethodKindEnum(6);
public static MethodKindEnum cast = new MethodKindEnum(7);
public static MethodKindEnum method = new MethodKindEnum(8);

private word counter;
private MethodKindEnum(const word counter) { this.counter = counter; }
}

class TypeName
{
private int nbDim = 0;
private vector<TypeNameComponent> components;
}

class TypeNameComponent
{
private bool isGeneric;
private string componentName;
private Vector<TypeName> genericComponents;
}

Argument/ResultType/MethodKind/TypeName/... should be modeled on the same way
the symbol package is modeled in the Nosica compiler ...
You get the idea.

Don't know yet if we have to specify wether a method should be declared as a
signal/slot ... After all, all we need is to make sure signatures are the
same... Will have to read QT doc to see if there is a more fundamental reason.
Anyway, it should not be too hard to add signal/slot declaration in front of
methods ...
Perhaps should we provide other usefull methods than connect (disconnect, ...) ...

Perhaps should we provide a complete reflexive package like a Class object that
models objects and are browsable at runtime, and of course a Field object ...

Any other thought ?