RLS Discussion Summary

Description

This document is the summary of the discussions about the RLS. The main discussion runs over the mailing list "platypus-discussion@lists.sourceforge.net". There are also some discussion forums, which you can find over our project summary page.

Description

This document is NOT OFFICIALLY part of the RUSL Language Specification 1 (RLS 1), it is just a summary of the discussion about RLS 1. Even if sections are marked as "final" here, they might be not final in the RLS 1 yet.

If you want to discuss with us about RUSL, please use the "platypus-discussion@lists.sourceforge.net" - mailing list. When you start a thread please add the title of the section/feature of this file. Please discuss only one section/feature in one discussion thread. If you want to start a new feature, please post it to the list so we can overtake it into this file.

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

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>

Description

IMHO the explicite cast should look like this: <cast target="FooClass"> barObject</cast>. But what about casts like (Namespace::Class)Object in c++? We couldn't handle such a cast with this structure. Here we'd need something like:

<cast>
<target>
<namespace name="Namespace">
<className name="Class"/>
</namespace>
</target>
<source>someObject</source>
</cast>
Sounds difficult, doesn't it?

Examples

See above.

Arguments

contra: No arguments found yet.