Language Design

Description

No matter how we do it, we should hide the source organisation as much as possible. The programmers should feel like navigating in one big tree when working on a project. The project organisation should be done once, and then nobody has to care about it anymore.

I know that this depends mainly on the IDE a programmer is working with, but we should design the language in a way to make this easy for IDEs.

Description

This feature discusses the pros / cons of namespaces like in c++, and what we should make completely different if we use such a structure.

I use here the word "namespace", maybe in most of the cases the word "package" would be ok too.

Description

One source file should contain EXACTLY ONE namespace, so we could make the namespace declaration an attribute of <source> or <rusl:source>, however it will be called then. Maybe we should also make name conventions for namespaces like the name conventions for packages in java. Nevertheless, namespaces should be independent from the source directory, IMHO.

Examples

<source namespace="net.sourceforge.platypus.builtin">

Arguments

pro: There would really only one namespace per source file, nothing else would be possible.

contra: We cannot structure the namespaces, i.e. we cannot determine that "net.sourceforge.platypus.builtin" is a sub namespace of "net.sourceforge.platypus"

Description

Here we could say that "net.sourceforge" is a sub-namespace of "net". See in examples.

Examples

<namespace name="net">
<namespace name="sourceforge">
<namespace name="platypus"/>
</namespace>
</namespace>

Arguments

pro: The xml-parser itself (or the tree it creates) would identify the namespace - structure.

contra: Just looking at it one could think that he can use more namespaces in the same file, just writing more such statements.

Description

To use a structure import - keyword. This would be similar (but not the same) to the "using" - directive in c++ or to the "import" - directive in java. See examples.

Examples

<import>
<namespace name="net">
<namespace name="sourceforge">
<namespace name="platypus"/>
</namespace>
</namespace>
</import>

Arguments

contra: No Arguments found yet.

Description

It should be possible to use namespaces / classes without explicitely importing them. Like "io.System.out.println()" in java or "MyNamespace::MyClass::printYourStatus" in c++.

Examples

How to do this one?

Description

Sometimes "import" - ing (or "using") a namespace is not a good idea, but you have to use some classes from that namespace. If that namespace has a pretty long name, and a shorter name would be unique in your context, it is useful if you have the possibility to rename it.

Examples

C++: namespace NLN = NamespaceWithVeryLongName;

Description

This section discusses how declarations of classes, objects, methods, parameters, ... are done in RUSL.

Description

We define two different statements for procedure and function declaration, i.e. procedureDecl and functionDecl.

Examples

Arguments

pro: We could apply different conditions/restrictions to functions/procedures.

pro: It might be useful for consistency

Description

This feature has not really been discussed before...

Maybe with <useClass select="ClassName"/>. This could also be used to build constructs like "AnyClass.anyObject":
>useClass select="AnyClass"><useObject select="anyObject"/></useClass>

Description

Instead of writing getter / setter methods for member objects of a class, and calling them every time a member object is needed, we could introduce "triggers". A trigger would be always called when an access to a variable is tryed, and then decide what to do with the request.

Leaving the write (read) trigger away could make a variable readonly (writeonly).

The keyword for this could be "readTrigger"/"writeTrigger" or just "getter"/"setter".

Examples

<variable name="fooObject" type="AnyClass">
<readTrigger>
<!-- Code which would be in the getFooObject() - method in other programming languages -->
</readTrigger>
</variable>