public class HasJustName{
    public abstract string Name;
}
public class HasAge{
    public abstract decimal Age;
}
public class HasNameAndSpouse{
    public abstract string Name;
    public abstract string Spouse;
}


public class Pirate{
    public decimal Age = 4.0; //caught assignement to string
    public string Name = "BlackBeard"; //caught mispelling
    public string Spouse = "Err";  
}

// *snip* Really cool, seems like implicit interface inheritance
HasNameAndSpouse Somebody = new Pirate; 
HasAge Somebody2 = new Pirate; 

public static decimal fac(decimal n){
 if(n == 0.0){
     return(1.0);
  }
  else{
   return(n * fac(n - 1.0)); //strongly typed. Really good. Did not allow arbitrary mixing of int and decimals
  }
}

public class Vehicle{
//public abstract void(){}
	public void vroom()
	{
		print "Vv";
	}
	//public void crash(Vehicle v)
	//{
	//	print "gen v crash";
	//}
}

public class Bike: Vehicle{
	//public abstract void(){}

}

public class Car : Vehicle{
	//public abstract void(){}
	public void vroom()
	{
		print "Cvvv";
	}
	public void crash(Bike b)
	{
            print "Bike"
	}
}



Vehicle v = new Car; //no sane rep when crash is added otherwise works

public static void main(){
print "Hello World";
print Somebody.Name;

print fac(24.0); //tail recursion?
//print  Somebody.Age; // not allowed good.
//local decimal k = Somebody2.Age; fail?
print fac(Somebody2.Age);
//v.vroom();
//local string s = Somebody.Name; error 
}

Now that Ive been playing with your code it looks like what you are doing is kinda like implementation inheritance via intersection of types (this is related too but not quite the same as the notion of intersection types since this relates strictly to inheritance).

So like suppose HasName = {string} and pirate = {string, int, int}

then HasName s = new pirate seems to be like tyepof s = typeof HasName ∩ typeof pirate = {string} where HasName ⊂ Pirate. So given abstract a, and concrete type t. then binding o : a to t() results in o : a where x in a => x in t . So the abstraction seems to be a restriction on Pirate. Ideally it should ;create an object that is a subset of t or can stand in for type t but this does not seem to work

I saw the section on inheritance and mixins but cant seem to find it anymore. Want to play with that some.

Will leave the below as an example of what not to do hehe.

public class HasNameAge{
    public abstract string Name; 
    public abstract int Age ;
}

public class Pirate{
    public int Age = 20;
    public int Hp = 5;
    public string Name = "BlackBeard";
}

public static void PrintAge(Pirate hna) // Failed cause Pirate not <: HasNamAge
{
  print (hna.Age);
}

HasNameAge Pete = new Pirate;  

public static void main(){
print "Hello World ";
print Pete.Name;
//print Pete.Hp;
PrintAge(Pete);
}

Enh... not so much. When you have HasName x = new Pirate;, the variable x is of type HasName. That's all the compiler knows, and cares about. It's a guarantee that the object will have a Name, so that's all you can use. The object is still a Pirate (so you can cast it back to Pirate once casting works), but the compiler checks that Pirate satisfied the guarantee that the object has a Name. No actual intersection there. And it will at this point give you errors if you try to assign something that is not a sub-type to a variable of a type.

An aside: Though intersection is in the code, and is used. It's currently only used when determining types for type inference during a generic method invocation. If a method with signature void(T,T) is passed an object,string it will properly infer that T is object. It also (perhaps unintuitively) if passed (AB,BC) will intersect the two, and allow you to call members of B. I am unsure if I'll provide intersection as a user callable Type expression operator yet. It seems to have limited uses, a little awkwardness, and tends to be unintuitive.

And no, you can't declare generic methods yet, but a little of the under-the-hood stuff is. The assignment operator's type for example is defined as operator void<T> assign(T,U) where U:T.

Agreed intersection types are unweildy, especially on .NET I do not think it would really be worth it.

I was editing while you replied so my last post was basically nonsense. Hopefully the edited one makes more sense. Its just me trying to understand the language. In terms of intersection I meant basic set intersection, was just trying to express an abstraction of the code.

This is quite flexible way to program with interface. Cool!

public static void PrintAge(HasNameAge hna) 
{
  local HasNameAge h = hna;
  print (h.Age);
}

Pirate Pete = new Pirate;  

public static void main(){
print "Hello World ";
print Pete.Name;
//print Pete.Hp;
PrintAge(Pete);

Well that is my report. =)

Quote:
I saw the section on inheritance and mixins but cant seem to find it anymore. Want to play with that some.

maybe?

Type Declarations

Implications of types as sets #2

If I remember correctly, declaring an inheritor in the type definition is not guaranteed to work in v0.1; I don't remember what in particular doesn't work. Probably anything involving name collisions, maybe inheriting goose types... not sure. [edit: hrm, looks like even the simple stuff isn't there yet. Oh well, it's in the queue.]

What should happen is that all members of the inheritee are mixed with the members declared in the body, yielding a new type which is the union of the two.