www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD v1.0 (again)

reply Kyle Furlong <kylefurlong gmail.com> writes:
Why don't we try and be definitive about what needs to get done before a 1.0
release? Walter may contribute his list as well. 
(this is really what I'm looking for) <g>
Mar 22 2006
next sibling parent reply John Demme <me teqdruid.com> writes:
Kyle Furlong wrote:

 Why don't we try and be definitive about what needs to get done before a
 1.0 release? Walter may contribute his list as well. (this is really what
 I'm looking for) <g>

With the recent DMD 0.150 Release I think there are four things that need to be done before 1.0: -Linux debugging symbols-- well... maybe not, but it needs to be there before I can really start hawking D ;) -Plaster all the documentation with recommendations to try Ares + Mango as an alternative to Phobos and instructions on how to do this. (I don't want to spark a debate on Mango vs Phobos, but I want Mango + Ares advertised as an option.) In the final packaging, it might be a good idea to include some popular D packages such as Mango + Ares, and Derek's build. (Also DDL, once it's done) -Linux shared object support This one's the most important one: -Anything with which Walter is not ABSOLUTELY satisfied with or believes to be a hack MUST be dealt with before 1.0. Now's your last chance to make changes which could break code, Walter... the bit vs bool change is a good example. I think we're getting close, but maybe I'm just really happy about the new interface stuff. ~John Demme
Mar 22 2006
parent reply BCS <BCS_member pathlink.com> writes:
John Demme wrote:
 Kyle Furlong wrote:
 
 
Why don't we try and be definitive about what needs to get done before a
1.0 release? Walter may contribute his list as well. (this is really what
I'm looking for) <g>

-Plaster all the documentation with recommendations to try Ares + Mango as an alternative to Phobos and instructions on how to do this. (I don't want to spark a debate on Mango vs Phobos, but I want Mango + Ares advertised as an option.) In the final packaging, it might be a good idea to include some popular D packages such as Mango + Ares, and Derek's build. (Also DDL, once it's done)

Full (or as much as doable) removal of runtime environment dependencys on Phobos.
 
 This one's the most important one:
 -Anything with which Walter is not ABSOLUTELY satisfied with or believes to
 be a hack MUST be dealt with before 1.0.  Now's your last chance to make
 changes which could break code, Walter... the bit vs bool change is a good
 example.
 

 ~John Demme

Mar 22 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
BCS wrote:
 John Demme wrote:
 Kyle Furlong wrote:


 Why don't we try and be definitive about what needs to get done before a
 1.0 release? Walter may contribute his list as well. (this is really 
 what
 I'm looking for) <g>

-Plaster all the documentation with recommendations to try Ares + Mango as an alternative to Phobos and instructions on how to do this. (I don't want to spark a debate on Mango vs Phobos, but I want Mango + Ares advertised as an option.) In the final packaging, it might be a good idea to include some popular D packages such as Mango + Ares, and Derek's build. (Also DDL, once it's done)

Full (or as much as doable) removal of runtime environment dependencys on Phobos.

Do you realize what this entails? Many, I repeat *MANY* language *features* are implemented in phobos.
 This one's the most important one:
 -Anything with which Walter is not ABSOLUTELY satisfied with or 
 believes to
 be a hack MUST be dealt with before 1.0.  Now's your last chance to make
 changes which could break code, Walter... the bit vs bool change is a 
 good
 example.

 ~John Demme


Mar 22 2006
parent reply BCS <BCS_member pathlink.com> writes:
Kyle Furlong wrote:
 BCS wrote:
 
 Full (or as much as doable) removal of runtime environment dependencys 
 on Phobos.

Do you realize what this entails? Many, I repeat *MANY* language *features* are implemented in phobos.

How about full documentation on what is used, enough so that they can be replaced.
Mar 22 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
BCS wrote:
 Kyle Furlong wrote:
 BCS wrote:

 Full (or as much as doable) removal of runtime environment 
 dependencys on Phobos.

Do you realize what this entails? Many, I repeat *MANY* language *features* are implemented in phobos.

How about full documentation on what is used, enough so that they can be replaced.

Mar 22 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Kyle Furlong wrote:
 Why don't we try and be definitive about what needs to get done before a 
 1.0 release? Walter may contribute his list as well. (this is really 
 what I'm looking for) <g>

Not much more for the language, I reckon. Anything that will break code. * AFAIK, the only new feature that needs to be done is the change to RAII syntax. * Rounding out a few of the recent features, especially IFTI. * Deprecate all undesirable features. I hope that this includes implicit declaration of printf, and reckless use of the comma operator. * No bugs in bugzilla of 'normal' or higher severity. (In practice, I'm now finding the biggest annoyance with the compiler is the way it dumps reams of incorrect error messages when it encounters a template any time after the first error). Of course, the library's a different story...
Mar 23 2006
next sibling parent kris <foo bar.com> writes:
Don Clugston wrote:
 (In practice, I'm now finding the biggest annoyance with the compiler is 
 the way it dumps reams of incorrect error messages when it encounters a 
 template any time after the first error).

Yes, that /does/ become tiresome rather quickly. Another primary one to keep in mind is better debugger support (arrays, classes, etc)
Mar 23 2006
prev sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Don Clugston wrote:
 Kyle Furlong wrote:
 Why don't we try and be definitive about what needs to get done before 
 a 1.0 release? Walter may contribute his list as well. (this is really 
 what I'm looking for) <g>

Not much more for the language, I reckon. Anything that will break code. * AFAIK, the only new feature that needs to be done is the change to RAII syntax. * Rounding out a few of the recent features, especially IFTI. * Deprecate all undesirable features. I hope that this includes implicit declaration of printf, and reckless use of the comma operator. * No bugs in bugzilla of 'normal' or higher severity. (In practice, I'm now finding the biggest annoyance with the compiler is the way it dumps reams of incorrect error messages when it encounters a template any time after the first error). Of course, the library's a different story...

I think the template error thing will be a deal breaker for C++ template types. Heres a senario: C++ guy reads about D v1.0 with cool new template system on /. C++ guy gets D v1.0 compiler (without template error messages fixed) C++ guy ports his sweet (so he thinks) template code to D C++ guy compiles... and WTF?!?! REAMS OF OUTPUT, from a simple noobie error C++ guy leaves D forever
Mar 23 2006
prev sibling parent reply Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Kyle Furlong wrote:

 Why don't we try and be definitive about what needs to get done
 before a 1.0 release? Walter may contribute his list as well.
 (this is really what I'm looking for) <g>

* 64 Bit support. That's a must. Or better: Arbitrary register length support. This of course means, that the ABI is built around the native length of pointers, pointer differences, etc. Wishes for D v1.1: * Eventually it may be good to have types like int8 int64 etc built into the language. In other languages (C/C++) this is done using a lot of ugly typedefs, or the compiler introduces types like __int8 which are then typedefed. Why not build this into the language? It won't break existing code, too (at least it doesn't "alias int int32; alias uint uint32;)" * It would be great to have RTTI without the same dirty tricks as performed in C++ (deriving everything from a common CObject class, etc). Make RTTI Information avaliable by introducing static and dynamic properties. * I'd like to have classes, interfaces and modules have a .inferface property (eventually name it a bit different to avoid clash with "normal" interfaces), that gives a data structure describing all methods and properties of a class and it's inheritance hierachy. The inheritance hierachy could be exposed by a property .super which has itself an .interface property and .super property. Just have a look at the dir(...) command of the python language and you get the idea. This capability of self description would make it much easier to expose classes to foreign modules loaded by dynamic loaders or being integrated into component systems or make it avaliable to script interpreters. I think of the following: import rtti; // get the types for RTTI foreach(rtti.method method, this.methods) { script_language_module.add_function(method.name, method.params); } method.params would be an array describing each parameter, eventually having a reference to other RTTI information again. Up to today no language, that creates compiled binary code has this feature. Only .net managed code is the closest thing to have this, but it's not native but gets converted to native code by a JIT compiler at runtime. * The other way would be cool, too, i.e. create a typed delegate from supplied method information. This delegate may then be used as callback or similair stuff. Through RTTI there is type safety and giving a mismatching delegate raises an exception. At the current state such delegates must be defined at compile time. Runtime function creation can be done with some dirty hacks, but still requires predefining the types. Normally this involves an associative array of an intermediary class that does the stack building and variadic functions. However this is not runtime safe. So such a class should be able to provide RTTI information. * By the way .net: D is IMHO an ideal language to support .net. Eventually we should try to add CLI output to the compilers for it. -- Wolfgang Draxinger
Mar 23 2006
parent Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Wolfgang Draxinger wrote:

 * It would be great to have RTTI without the same dirty tricks as
 performed in C++ (deriving everything from a common CObject
 class, etc). Make RTTI Information avaliable by introducing
 static and dynamic properties.
 ...

D'oh: I've now seen, that this is already provided or intended to be done by Phobos. Ahm, I should really read more on the standard libraries and not just focus on the language spec. Wolfgang Draxinger
Mar 28 2006