www.digitalmars.com         C & C++   DMDScript  

D - Additional ideas for features

reply Stefan Staiger <Stefan_member pathlink.com> writes:
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
Jan 26 2003
next sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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
Jan 26 2003
prev sibling parent "Ken Carpenter" <kencr shaw.ca> writes:
 (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
Jan 27 2003