Ideas For The Next Generation Of Programming Languages
This blog post deals with a vareity of things I feel would be nice to have features in the next generation of programming languages. I keep learning about compiler technology and I am hoping that in the next few years, I will be able to build a compiler for a full fledged language that incorporates the following ideas as well as great ideas from other programming languages.
Integrated Factory Pattern
This is one feature I have no idea about how to implement. But, it would be nice to have.
The idea is that one can write this code
public
interface IElementFactory
{
public static IElement CreateElement (string name);
}
[DefaultFactory(typeof(SimpleElementFactory))]
public static class AbstractElementFactory : IElementFactory
{
public static IElement CreateElement (string name);
}
Then, the compiler can generate the appropriate glue code that looks something like this
[DefaultFactory(typeof(SimpleElementFactory))]
public static class AbstractElementFactory : IElementFactory
{
[MethodImpl(MethodImplOptions.Synchronized)]
public static IElement CreateElement (string name)
{
if (null == Instance)
Instance =
new default();
return Instance.CreateElement (name);
}
private static IElementFactory Instance
{
get;
set;
}
public static void Register (IElementFactory factory)
{
Debug.Assert(null != factory);
if ( null == factory )
throw new ArgumentNullException ("factory");
Instance = factory;
}
}
and further, recognize the following entry in the configuration to instantiate and register the appropriate factory instance by default.
<factoryConfig name=
"X.Y.Z.AbstractElementFactory" register="XYZElementFactory" params="1,2,3,4,5"/>
Meta-data describing parameter usage.
A programming language like C# already has some of this. For example, you can specify parameters as being out, in, ref. But, what if we could do something like
public bool [checked] CreateObject ( string name [!= null, .Length > 0, ~= '(?:parse)'], readonly ref IList<string> stringList, ref readonly IList<string> sourceList [!= null, .Count > 0, foreach (~= '(?:Test)')]
In the above, the [checked] meta-keyword on the return type indicates to the compiler that the return value from this method must be checked by the caller. For the first parameter, 'name', the restrictions between [ and ] are a combination of properties and meta's. I think the implication of what this is enforcing is clear. In this case, the compiler automatically generates the appropriate Debug.Assert and throw new ArgumentException statements for the given restrictions. Besides, having this as part of the code makes it abundantly clear to developers perusing the code as well as those looking at the documentation and most importantly testers what the expected input is. This makes it even easier for automatic test generators to generate both positive and negative test data thus obviating the need to write boiler plate code. We can of course extend this type of declarative restriction system using more complex rules.
Validation for automatic properties.
I would love to retain the syntactic sugar of automatic-properties coupled with meta-data specified validation and initialization method invocation.
How could this work? Consider the following example:
public class Foo
{
public string Name
{
get;
set;
}
}
We can do this today in C#. However, AFAIK, if you wanted to add validation to the above, you would have to then provide the field that the property wraps, as well as adding in the validation code. I would rather have this specified like this:
public string Name
{
get;
set;
validate ( string value )
{
if ( null == value || value.Length <= 0)
throw new ArgumentException("Cannot be NULL or empty.", "Name");
}
initialize ()
{
return "FooBar";
}
}
where the methods validate and initialize are implicitly private, implicitly return void and string respectively, are invoked when the setter is invoked and invoked the first time the getter is invoked respectively. This is far more self-contained and makes more readable code since I don't have to
- Implement a private field to provide storage for the property.
- Implement private methods separate from the property and hence potentially invocable by others.
- Scroll back and forth in code.
Syntactic sugar for auto-delegation.
It would be so good to have syntactic sugar for auto-forwarding non-implemented interface/abstract inherited methods to a contained instance.
For example, let us say I have an interface I. There is an existing class hierarchy consisting of classes X, Y and Z where Z is-a Y and Y is-a X. Now, I want to introduce a bunch of additional classes C1 through CF (that's 16 of them) each of which inherit from Z and also implement the interface I. Now, let's say, all I am doing is defining some properties in I. Ideally, I would have been able to implement all the properties in a class IImpl and then allow C1 through CF to multiple inherit from Z and IImpl. Since that is increasingly becoming not possible in many languages such as Java and C#, it would be nice to have this instead:
public class Ci : Z, I [forward: IImpl:iImplementationInstance]
{
// just Ci behavior.
}
What's the sugar here? I interface method invocations on Ci get auto-forwarded to the contained instance iImplementationInstance of type IImpl. Whoohoo!
Access control on fields by methods.
Defaulting of default values for properties and fields through meta-data.
Declarative syntax for graph like object hierarchy navigation.
Aspect oriented programming features.
Executing program inspection built into the language.
Program directed compilation.
Code templatization invoked by the compiler.
Pattern systems built into the language.
Rule system for specifying dependencies among types in generic types.
Rule system for specifying inter-dependencies among values for data types.