I designed an object system, which appears to be brilliant. This is the defining part of my upcoming programming language.
Every value has an interface, which is a dictionary that describes how the values with that interface behave. The list interface dictionary might look like this:
append count extend index remove length +construct +init +concat +getitem +setitem +iter
Interfaces themselves have interface, which might look like this:
Interpreter would query this interface when you fondle your lists. So say the interface name would be
list, just like in python. Lets unmystify it with an example. Consider this program:
hello = list() hello.append(1) hello.append(2) print("length: ", hello.length) print("second element: ", hello)
Here's what would happen:
list()goes through the base interface, which uses
+initto create the list. The
+constructallocates the object while
+initinitializes the contents.
hello.append(1)looks for interface of the list, finds the
appendin the interface and calls it with the value, list is passed in special
hello.lengthlooks for interface of the list, finds the
length-entry in the interface dictionary. The value is resolved with
+get(this)in the entry's interface.
+getitemin the entry's interface and calls it, with the list in the
The interface is used to resolve the source of different values. This provides an illusion that any user defined object can define same behavior as system defined objects.
If the attribute isn't found from the interface dictionary, the dictionary can define
+setattr. With these interface fields one can produce objects that have arbitrary members, just like in python.
The callable objects have
+call in their interfaces. For situations when object itself is field, or otherwise a member of another object, it always gets
this -member as argument, which is the
@ passed to a regular function. This makes sure that the functions in value slots or an "ex nihilo" object behave similar to the functions in the interface.
Here's a partial summary about what an interface dictionary can hold:
object interface method(args...) +construct(args...) +init(args...) +callattr(name, args...) +setattr(name, value) +getattr(name) +call(this, args...) +add(other) +sub(other) field interface +get(this) +set(this, value) +call(this, args...)
I think this can be:
- Comfortable for a beginner
- Help optimization attempts
- Powerful in hands of a skilled user
- The best damn object system for a dynamic programming language
I'm writing this into my language runtime. We'll see in few weeks whether I was right about it.