OOP Languages – Designing a Module System

designmodulesobject-orientedprogramming-languagesvirtual-machine-languages

I'm designing a simple OO programming language.

It's statically typed, compiled, and executed by a VM – similar to Java.

The difference is that I don't want to have such a strong emphasis on OOP. The code itself will mostly resemble C++ (classes, functions, and variables allowed in the file scope).

One of the things that I need to have is a module system. I have the following figured out:

Every file is a module (once compiled) – like Python
Programmers must import a module with the import keyword, which causes the compiler to search for modules in standard directories and the file directory (the VM has to do this at runtime as well)

And now I have no idea how should I introduce the concept of submodules and module hierarchy.

One option, for example, is to depend on the directory hierarchy, so that import engine.graphics.renderer would expect to find a directory called "engine" in the working directory, and inside a directory called "graphics", with a module called "renderer".

What are the drawbacks of such a design? Am I missing anything?

Best Answer

Take a look at Python's package/module hierarchy/organization, and especially in historical aspect, major additions over the course of years, most importantly the latest ones. Probably, there is no sense in inventing the wheel.

I do not know how far you want to go with your language, eg

Do you want modules bytecode to be read from zip?
How do you separate modules/libraries for different interpreter versions?
Do you plan to make it seemless with distros?
Do not forget easiness of language's own distribution (think distutils / pypi - each platform/language has its own, not always good)

I guess, Java may be another interesting example. Things can be learned from Erlang's way as well (eg https://stackoverflow.com/questions/2968914/code-hot-swapping-in-erlang).

There is a whole lot of design issues (some touched above) if you plan to see your programming language mainstream one day. Fortunately, there are great examples out there.

Some directions programming language module/package/library system design should address:

intuitive code for both writing and using the module
module/package objects in the code
module/package introspection capabilities
module/package encapsulation (how to hide unnecessary details?)
use of interfaces/header files?
fine-graned dispatching system, which both language own distribution utils as well as system level utils can use (avoid "DLL hell")
storage places for bytecompiled modules
setup system, which automates compiling both "pure" modules and modules/dependencies
canonical place of compiled code, tests, documentation, assets in your module

Related Solutions

Is Python Interpreted or Compiled? Understanding Python Execution

It's worth noting that languages are not interpreted or compiled, but rather language implementations either interpret or compile code. You noted that Ruby is an "interpreted language", but you can compile Ruby à la MacRuby, so it's not always an interpreted language.

Pretty much every Python implementation consists of an interpreter (rather than a compiler). The .pyc files you see are byte code for the Python virtual machine (similar to Java's .class files). They are not the same as the machine code generated by a C compiler for a native machine architecture. Some Python implementations, however, do consist of a just-in-time compiler that will compile Python byte code into native machine code.

(I say "pretty much every" because I don't know of any native machine compilers for Python, but I don't want to claim that none exist anywhere.)

Object-oriented – Designing an easily extensible XML driven OOP system

The design you indicated is missing an important feature - flexible XML formatting of new conditions. Based on your post, this wouldn't be possible:

<condition ...>
    <pieceCombos>
        <combo>...</combo>
        <combo>...</combo>
    </pieceCombos>
</condition>

An better way would be to have each of these classes know how to read (and write) their own information from the appropriate xml element. So something like this could be cleaner and more flexible:

// This abstracts away specific methods of reading from xml.
public class YourXmlHandler
{
    ...
    GetChildElement(int index);
    GetAttribute(int index);
    ...
}

public interface IXmlReadable
{
    void LoadFromXml(YourXmlHandler reader);
}

public interface IWinOption
{
    bool Evaluate();
}

This allows you to reuse the IXmlReadable interface for anything affected by the XML content. It leaves the win option separate for the items that must be Wins.

You may end up with a WinConditions class that knows to read multiple WinCondition entries from the XML and a Pieces class that knows how to read its data. The WinCondition class knows exactly what it wants from the XML and just gets it or throws a meaningful exception.

Best Answer

Related Solutions

Is Python Interpreted or Compiled? Understanding Python Execution

Object-oriented – Designing an easily extensible XML driven OOP system

Related Topic