Hi there,

I've read through your D documentation,
and I must say that the idea seems to be really good.

From my personal experience in programming with C++,
I've still got two more ideas that could make sense,
so I'll post them here:

(i) Properties as in Borland's C++-Builder

This is about data fields of a class. Often, you will make
such a field 'private' to the class and offer the
well-known 'get' and 'set' methods to allow controlled
access to the field. Borland's properties now
simplify the access in that you can directly use
the field as if it were declared private, and the compiler
instead replaces such an access with the correct function call.
For that, the class field is declared with something like
property int MyField = {read = GetField, write = SetField};
where GetField and SetField are methods of the same class.
With that, a statement like
MyObject.MyField = 5;
will be replaced by the compiler with
MyObject.SetField(5);

If you don't specify a 'write'-method for a property,
it'll be read-only.

(ii) Why still use textual source files ?

I'm just wondering why most if not all programming languages
use standard text files as source files. Wouldn't it make
sense to use some standardized format instead, optimized for
the tools that need to work on it (mainly the compiler) ?
Of course, then you can't use a normal text editor, but instead
a special editor which now also can offer better support
for programming. In general, writing tools would be much easier,
and those tools will be able to offer much better support.
We simply take advantage of the fact that the internal
representation of the *file* needn't be the same as the
external view on it, the *program*'s source. This view then
can for example also be more adapted to humans, e.g.
more graphically for complex design tasks (towards UML or so).

Stefan

Hi

"Stefan Staiger" <Stefan_member@pathlink.com> wrote in message news:b10m6j$nbc$1@digitaldaemon.com...
> Hi there,
>
> I've read through your D documentation,
> and I must say that the idea seems to be really good.
>
> From my personal experience in programming with C++,
> I've still got two more ideas that could make sense,
> so I'll post them here:
>
> (i) Properties as in Borland's C++-Builder
>
> This is about data fields of a class. Often, you will make
> such a field 'private' to the class and offer the
> well-known 'get' and 'set' methods to allow controlled
> access to the field. Borland's properties now
> simplify the access in that you can directly use
> the field as if it were declared private, and the compiler
> instead replaces such an access with the correct function call.
> For that, the class field is declared with something like
> property int MyField = {read = GetField, write = SetField};
> where GetField and SetField are methods of the same class.
> With that, a statement like
> MyObject.MyField = 5;
> will be replaced by the compiler with
> MyObject.SetField(5);
>
> If you don't specify a 'write'-method for a property,
> it'll be read-only.

These are in the D specification, but not implemented yet in the alpha compiler.

> (ii) Why still use textual source files ?
>
> I'm just wondering why most if not all programming languages
> use standard text files as source files. Wouldn't it make
> sense to use some standardized format instead, optimized for
> the tools that need to work on it (mainly the compiler) ?
> Of course, then you can't use a normal text editor, but instead
> a special editor which now also can offer better support
> for programming. In general, writing tools would be much easier,
> and those tools will be able to offer much better support.
> We simply take advantage of the fact that the internal
> representation of the *file* needn't be the same as the
> external view on it, the *program*'s source. This view then
> can for example also be more adapted to humans, e.g.
> more graphically for complex design tasks (towards UML or so).

D supports embedding the D sourcecode in a HTML document.  Not 100% what you wanted, but doesn't require a specialized code editor.  You can do some pretty cool stuff with that.

Sean

> (ii) Why still use textual source files ?
>
> I'm just wondering why most if not all programming languages
> use standard text files as source files. Wouldn't it make
> sense to use some standardized format instead, optimized for
> the tools that need to work on it (mainly the compiler) ?
> Of course, then you can't use a normal text editor, but instead
> a special editor which now also can offer better support
> for programming. In general, writing tools would be much easier,
> and those tools will be able to offer much better support.
> We simply take advantage of the fact that the internal
> representation of the *file* needn't be the same as the
> external view on it, the *program*'s source. This view then
> can for example also be more adapted to humans, e.g.
> more graphically for complex design tasks (towards UML or so).

Nobody says you can't use your own storage format.
IBM is doing this with their VisualAge products, storing
"code" in a database.

Just generate the text-based source code at compile time
or in a background thread as the program is modified
and pass it to a regular D compiler.  Or if your prefer,
implement your own D compiler that understands your
special format.

Source code can also be "exported" to text format for
exchange between different development environments
and platforms.

The way Walter is splitting up the lexical analyser and parser should allow for easier tool development.  I do wonder, though, if some standard tokenized and parsed formats would be useful here.

An XML-based parse tree maybe?  I haven't looked
into what the D parser outputs right now though, so
maybe it already does this.


Ken Carpenter