www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.163 release

reply Walter Bright <newshound digitalmars.com> writes:
http://www.digitalmars.com/d/changelog.html

This has all the new import changes in it. That breaks a lot of existing 
code (like dmdscript), the fixes are simple (adding more import 
declarations) but tedious.

I couldn't find a better keyword choice than "static import".

The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:

1) didn't want to add new keywords, especially ones like 'as' as I use 
that as a variable name

2) didn't need to add new keywords - adding them should be done only if 
using punctuation is completely unappealing

3) using '=' and ':' is visually more distinct than embedded keywords.
Jul 18 2006
next sibling parent BCS <BCS pathlink.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

Thanks!! I'll try it out soon.
Jul 18 2006
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing
 code (like dmdscript), the fixes are simple (adding more import
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

Whatever harsh words I came with a week ago, they are forgotten. A wonderful release :D (Especially since I don't see the need for the static version so I won't ever be bothered by the presence of the static keyword.) -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jul 18 2006
prev sibling next sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Walter Bright wrote:

 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing code
 (like dmdscript), the fixes are simple (adding more import declarations) but
 tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use that
 as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if using
 punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

Thank you for solving this import issues. Great step forward for modular programming in D. --
Jul 18 2006
prev sibling next sibling parent John Reimer <John_member pathlink.com> writes:
In article <e9jfdd$1sb0$1 digitaldaemon.com>, Walter Bright says...
http://www.digitalmars.com/d/changelog.html

This has all the new import changes in it. That breaks a lot of existing 
code (like dmdscript), the fixes are simple (adding more import 
declarations) but tedious.

I couldn't find a better keyword choice than "static import".

The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:

1) didn't want to add new keywords, especially ones like 'as' as I use 
that as a variable name

2) didn't need to add new keywords - adding them should be done only if 
using punctuation is completely unappealing

3) using '=' and ':' is visually more distinct than embedded keywords.

Walter, just want to voice my thanks also: thanks for listening in regards to the imports issues. It really seems you put some work into implementing a balanced solution that meets different peoples needs. It's a real challenge to convince you, and it seems we still have to find out where you are most vulnerable to being convinced ;) (C++ angle mostly, it seems, unfortunately; and, no I don't believe you are convinced by good solid evidence: you are quite biased in your opinions). Nonetheless, thanks for going the distance despite the upheaval that took place. What you do is not unnoticed! Those of us working hard to make D stand out in this world really want to see D at it's best. -JJR
Jul 18 2006
prev sibling next sibling parent xs0 <xs0 xs0.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html

Great work, thanks! xs0
Jul 18 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

Thanks, I'm trying this new sutff out! P.S. I just noticed a "bug" on the website: I'm using IE7 (Beta 3) and the download link on the top doesn't work unless I point the mouse at the top edge of the "box".
Jul 18 2006
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

*Imports now default to private instead of public. Breaks existing code.* Horray! :) This shouldn't break too much of my code because I already use 'private import' everywhere. *Object.opCmp now throws an error. Should override it if used. Breaks existing code.* Can someone spell this out for me? *confused* *Added static imports, renamed imports, and selective importing.* Can someone show me how this is supposed to work as well? *confused* Thanks! Nice to see some positive changes. ~ Clay
Jul 18 2006
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
clayasaurus wrote:
 Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html

 This has all the new import changes in it. That breaks a lot of 
 existing code (like dmdscript), the fixes are simple (adding more 
 import declarations) but tedious.

 I couldn't find a better keyword choice than "static import".

 The renaming uses '=' instead of 'as', 'from', or 'alias' for the 
 reasons:

 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name

 2) didn't need to add new keywords - adding them should be done only 
 if using punctuation is completely unappealing

 3) using '=' and ':' is visually more distinct than embedded keywords.

*Imports now default to private instead of public. Breaks existing code.* Horray! :) This shouldn't break too much of my code because I already use 'private import' everywhere. *Object.opCmp now throws an error. Should override it if used. Breaks existing code.* Can someone spell this out for me? *confused*

If you write a class that does not override "opCmp", it is now a runtime error to attempt to compare instances of it: class A { } void main() { A a = new A; A b = new A; if (a < b) { // Error is thrown // ... } } Previously, the base Object class defined opCmp to compare the addresses in memory of the two instances (or something like that). Thus, it worked, but did nothing particularly useful, except insofar as "opCmp" always compared /something/. (This can be useful when writing, e.g. some templated container classes.) I think this is probably a good change.
 *Added static imports, renamed imports, and selective importing.*
 
 Can someone show me how this is supposed to work as well? *confused*
 

The best explanation is in the spec: http://www.digitalmars.com/d/module.html#ImportDeclaration On a slightly related note, I have updated my keyword index with the new meaning of "static": http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification/KeywordIndex
 
 Thanks! Nice to see some positive changes.
 
 ~ Clay
 

-- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 18 2006
parent clayasaurus <clayasaurus gmail.com> writes:
Kirk McDonald wrote:
 clayasaurus wrote:
 Walter Bright wrote:

 http://www.digitalmars.com/d/changelog.html

 This has all the new import changes in it. That breaks a lot of 
 existing code (like dmdscript), the fixes are simple (adding more 
 import declarations) but tedious.

 I couldn't find a better keyword choice than "static import".

 The renaming uses '=' instead of 'as', 'from', or 'alias' for the 
 reasons:

 1) didn't want to add new keywords, especially ones like 'as' as I 
 use that as a variable name

 2) didn't need to add new keywords - adding them should be done only 
 if using punctuation is completely unappealing

 3) using '=' and ':' is visually more distinct than embedded keywords.

*Imports now default to private instead of public. Breaks existing code.* Horray! :) This shouldn't break too much of my code because I already use 'private import' everywhere. *Object.opCmp now throws an error. Should override it if used. Breaks existing code.* Can someone spell this out for me? *confused*

If you write a class that does not override "opCmp", it is now a runtime error to attempt to compare instances of it: class A { } void main() { A a = new A; A b = new A; if (a < b) { // Error is thrown // ... } } Previously, the base Object class defined opCmp to compare the addresses in memory of the two instances (or something like that). Thus, it worked, but did nothing particularly useful, except insofar as "opCmp" always compared /something/. (This can be useful when writing, e.g. some templated container classes.) I think this is probably a good change.
 *Added static imports, renamed imports, and selective importing.*

 Can someone show me how this is supposed to work as well? *confused*

The best explanation is in the spec: http://www.digitalmars.com/d/module.html#ImportDeclaration On a slightly related note, I have updated my keyword index with the new meaning of "static": http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification/KeywordIndex

Thanks! ~ Clay
Jul 18 2006
prev sibling next sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

omg it's uber!!111 Imports private by default, I likey. Thanks Walter!
Jul 18 2006
prev sibling next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

Excellent! -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 18 2006
parent Walter Bright <newshound digitalmars.com> writes:
Kirk McDonald wrote:
 Excellent!

Thanks. I wanted to get all this done, as I want to spend some time putting the engine back in my car. I wanted to do it today, but I stupidly broke the motor mount and had to spend an hour getting a new one, then I found out I need a different chain for the hoist, ... Hopefully, tomorrow I can get the durn thing back in. It's been nearly 2 years.
Jul 18 2006
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

Default private imports are a fantastic thing long in coming! Thank you Walter. Also, while I still have some minor reservations on using the 'static' keyword in this way, I very much love the new additions to the import system. I look forward to collapsing some long names down to something more feasible, and to yoinking one or two functions from a utility module without further polluting my namespace (and without having to resort to qualified names when they aren't the summit of elegance). I am intrigued by the exact syntax you settled on, in particular the use of ':' to do selective importing. There are just a couple things that I wonder about. Is it possible to do a static selective import? In other words: # static import foo : bar ; // must use 'foo.bar' to refer to it Or to do a static renamed selective import, even: # static import abc = foo : def = bar ; // must use 'abc.def', which defers to 'foo.bar' And I assume there is no way to import more than one module selectively in one module declaration, since there is no syntax to terminate the symbol list after the ':' terminal, aside from ending the declaration altogether. One last time: hooray for default private imports! ;) You are an amazing individual, Mr. Bright. And D is an amazing language. -- Chris Nicholson-Sauls
Jul 18 2006
parent Walter Bright <newshound digitalmars.com> writes:
Chris Nicholson-Sauls wrote:
 Is it possible to do a static selective import?  In other words:
 # static import foo : bar ; // must use 'foo.bar' to refer to it

No.
 Or to do a static renamed selective import, even:
 # static import abc = foo : def = bar ; // must use 'abc.def', which 
 defers to 'foo.bar'

No.
 And I assume there is no way to import more than one module selectively 
 in one module declaration, since there is no syntax to terminate the 
 symbol list after the ':' terminal, aside from ending the declaration 
 altogether.

That's right. You'll need to do it as a separate declaration.
 One last time: hooray for default private imports!  ;)  You are an 
 amazing individual, Mr. Bright.  And D is an amazing language.

Thank-you (!)
Jul 18 2006
prev sibling next sibling parent reply David Medlock <noone nowhere.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

I am sure you are tired of hearing it Walter, but You Da Man! =D -DavidM
Jul 18 2006
parent Walter Bright <newshound digitalmars.com> writes:
David Medlock wrote:
 I am sure you are tired of hearing it Walter, but You Da Man!

No, I never tire of that <g>. "You're welcome" to all here who said thanks.
Jul 18 2006
prev sibling next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

I just updated Pyd to work with 0.163 (which was pretty painless), and uncovered a pecular bug. I can't seem to reproduce the exact error with a small example, but (in short) it doesn't seem to like source files named "object.d". Renaming the source file in question (to "dpyobject.d", which is actually a more fitting name and a change I've been meaning to make) solved the problem. For what it's worth, the precise compiler error was: C:\Python24\lib\site-packages\celerid\infrastructure\pyd\object.d(41): identifier 'Object' is not defined C:\Python24\lib\site-packages\celerid\infrastructure\pyd\object.d(41): Object is used as a type Assertion failure: 'b->type->ty == Tclass' on line 342 in file 'class.c' Line 41 is the top of the DPyObject class. It looks like, by calling my file object.d, it was somehow masking Phobos's object.d, and thus the Object class could not be found to subclass DPyObject from. Whatever. I renamed the file and it is now happy. -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 18 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Kirk McDonald wrote:
 I just updated Pyd to work with 0.163 (which was pretty painless), and 
 uncovered a pecular bug. I can't seem to reproduce the exact error with 
 a small example, but (in short) it doesn't seem to like source files 
 named "object.d". Renaming the source file in question (to 
 "dpyobject.d", which is actually a more fitting name and a change I've 
 been meaning to make) solved the problem.

Yes, "object.d" is special and must be the Phobos one that defines "Object". The compiler assumes it is, and gets all confused if it isn't.
Jul 18 2006
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Kirk McDonald wrote:
 Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html

 This has all the new import changes in it. That breaks a lot of 
 existing code (like dmdscript), the fixes are simple (adding more 
 import declarations) but tedious.

 I couldn't find a better keyword choice than "static import".

 The renaming uses '=' instead of 'as', 'from', or 'alias' for the 
 reasons:

 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name

 2) didn't need to add new keywords - adding them should be done only 
 if using punctuation is completely unappealing

 3) using '=' and ':' is visually more distinct than embedded keywords.

I just updated Pyd to work with 0.163 (which was pretty painless), and uncovered a pecular bug. I can't seem to reproduce the exact error with a small example, but (in short) it doesn't seem to like source files named "object.d". Renaming the source file in question (to "dpyobject.d", which is actually a more fitting name and a change I've been meaning to make) solved the problem. For what it's worth, the precise compiler error was: C:\Python24\lib\site-packages\celerid\infrastructure\pyd\object.d(41): identifier 'Object' is not defined C:\Python24\lib\site-packages\celerid\infrastructure\pyd\object.d(41): Object is used as a type Assertion failure: 'b->type->ty == Tclass' on line 342 in file 'class.c' Line 41 is the top of the DPyObject class. It looks like, by calling my file object.d, it was somehow masking Phobos's object.d, and thus the Object class could not be found to subclass DPyObject from. Whatever. I renamed the file and it is now happy.

If I recall right, I managed to actually get this to work with a couple of requisites. 1 - The local module 'object' MUST be in a package. In other words, 'foo.object' can be made to work, but 'object' cannot. 2 - If the local module 'object' defines any classes, it should PUBLICLY import 'object' (no package; the Phobos module 'object') and should also explicitly declare its classes as children of 'object.Object'. Although if using a different name for the module works well, then by all means do so. :) Also, I don't think one can use the name 'Object' for a class regardless. Unless... well, maybe our new 'static import' would obviate that restriction... I might have to experiment with that later. -- Chris Nicholson-Sauls
Jul 19 2006
prev sibling next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 18 Jul 2006 13:13:37 -0700, Walter Bright wrote:

 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.

Thanks Walter. v0.163 compiled Build and all its modules without having to change a single line of code. None of my code was broken with this release. However, I will need to upgrade Build to cater for the new module renaming syntax ASAP.
 I couldn't find a better keyword choice than "static import".

Given that the form "static import XXX" and "import XXX = whatever" both require XXX to be used when referencing members, the 'static' import is only required when one is not renaming the module, eg. "import io = std.stdio;" and "static import io = std.stdio;" are identical, I sort of liked the idea that dropped the need for 'static' and if one wanted to force FQN using the normal module name, one could have written "import std.stdio = std.stdio;". -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 19/07/2006 2:01:37 PM
Jul 18 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:
 Given that the form "static import XXX" and "import XXX = whatever" both
 require XXX to be used when referencing members, the 'static' import is
 only required when one is not renaming the module, eg.   "import io =
 std.stdio;" and "static import io = std.stdio;" are identical, I sort of
 liked the idea that dropped the need for 'static' and if one wanted to
 force FQN using the normal module name, one could have written "import
 std.stdio = std.stdio;".

I thought of that too, but it would be a weird special case, as having: import foo.bar = std.stdio; would be quite bizarre.
Jul 18 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 18 Jul 2006 23:36:03 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 Given that the form "static import XXX" and "import XXX = whatever" both
 require XXX to be used when referencing members, the 'static' import is
 only required when one is not renaming the module, eg.   "import io =
 std.stdio;" and "static import io = std.stdio;" are identical, I sort of
 liked the idea that dropped the need for 'static' and if one wanted to
 force FQN using the normal module name, one could have written "import
 std.stdio = std.stdio;".

I thought of that too, but it would be a weird special case, as having: import foo.bar = std.stdio; would be quite bizarre.

Hmmm... what about ... the situation where I use FQN with a utility module of some sort, but later I want to try out something different that might not make the cut. Instead of relocating files or adding mountains of version statements or recoding to use renamed modules, I could've done ... version(SuperTest) import util.string = debug.string; else import util.string; . . . util.string.somefunc(); . . . util.string.anotherfunc(); . . . util.string.yaf(); Anyhow, just a thought. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 19/07/2006 5:08:20 PM
Jul 19 2006
prev sibling parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"Derek Parnell" <derek nomail.afraid.org> 
??????:12pinsuw7ixot$.1uioiq6i09vc2$.dlg 40tude.net...
 On Tue, 18 Jul 2006 13:13:37 -0700, Walter Bright wrote:

 http://www.digitalmars.com/d/changelog.html

 This has all the new import changes in it. That breaks a lot of existing
 code (like dmdscript), the fixes are simple (adding more import
 declarations) but tedious.

Thanks Walter. v0.163 compiled Build and all its modules without having to change a single line of code. None of my code was broken with this release. However, I will need to upgrade Build to cater for the new module renaming syntax ASAP.
 I couldn't find a better keyword choice than "static import".

Given that the form "static import XXX" and "import XXX = whatever" both require XXX to be used when referencing members, the 'static' import is only required when one is not renaming the module, eg. "import io = std.stdio;" and "static import io = std.stdio;" are identical, I sort of liked the idea that dropped the need for 'static' and if one wanted to force FQN using the normal module name, one could have written "import std.stdio = std.stdio;".

If we can use FQN access a symbol directly, not need any importing, all things going bo be consistent and natural. int main(void) { std.stdio.writefln("Just do it"); // not need any importing ... }
 -- 
 Derek
 (skype: derek.j.parnell)
 Melbourne, Australia
 "Down with mediocrity!"
 19/07/2006 2:01:37 PM 

Jul 19 2006
parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
 If we can use FQN access a symbol directly, not need any importing, all
 things going bo be consistent and natural.
 
 int main(void)
 {
    std.stdio.writefln("Just do it"); // not need any importing
    ...
 }

Well, it's how C# (and other .NET languages) does that. But I think explicit module declarations are more informative (you just look at the beginnig of the file to find out what it depends on) and also aids tools like Build (no need to parse all the code to figure out dependencies) --
Jul 19 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Andrei Khropov wrote:
 If we can use FQN access a symbol directly, not need any importing, all
 things going bo be consistent and natural.

 int main(void)
 {
    std.stdio.writefln("Just do it"); // not need any importing
    ...
 }

Well, it's how C# (and other .NET languages) does that. But I think explicit module declarations are more informative (you just look at the beginnig of the file to find out what it depends on) and also aids tools like Build (no need to parse all the code to figure out dependencies)

I agree. There needs to be some 'anchor' that says where the names are coming from. Otherwise, the compiler can't tell the difference between an undefined identifier and a file not found. Even worse, a misspelled identifier can result in some odd module being imported, and all kinds of mischief. Just like implicit declaration of variables is a bad idea, implicit importing is a bad idea.
Jul 19 2006
parent "Boris Wang" <nano.kago hotmail.com> writes:
OK, I agree.

But, we need a fix for the redundancy, 'static import =' and 'import ='.

It's so ugly.


"Walter Bright" <newshound digitalmars.com> 
??????:e9mhnd$fmn$1 digitaldaemon.com...
 Andrei Khropov wrote:
 If we can use FQN access a symbol directly, not need any importing, all
 things going bo be consistent and natural.

 int main(void)
 {
    std.stdio.writefln("Just do it"); // not need any importing
    ...
 }

Well, it's how C# (and other .NET languages) does that. But I think explicit module declarations are more informative (you just look at the beginnig of the file to find out what it depends on) and also aids tools like Build (no need to parse all the code to figure out dependencies)

I agree. There needs to be some 'anchor' that says where the names are coming from. Otherwise, the compiler can't tell the difference between an undefined identifier and a file not found. Even worse, a misspelled identifier can result in some odd module being imported, and all kinds of mischief. Just like implicit declaration of variables is a bad idea, implicit importing is a bad idea.

Jul 19 2006
prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
Walter, I'm glad you made these 'breaking changes'. Now is the right time to 
do this, and people won't mind 'fixing' their code. I think most people will 
actually be eager to adapt their code.

Thanks,

L. 
Jul 19 2006
parent Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:
 Walter, I'm glad you made these 'breaking changes'. Now is the right time to 
 do this, and people won't mind 'fixing' their code. I think most people will 
 actually be eager to adapt their code.

And actually, the fixes I made to DMDScript as a result of this did result in clearer code. So, it's all to the best.
Jul 19 2006
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Is this silly mistake new, or has it gone unnoticed all this time?

http://www.digitalmars.com/d/operatoroverloading.html

"Note: Comparing a reference to a class object against null  should be 
done as:

     if (a is null)

and not as:

     if (a == null)

The latter is converted to:

     if (a.opCmp(null))

which will fail if opCmp() is a virtual function."

Two problems:
(a) you've got opCmp mixed up with opEquals
(b) it makes no sense that this is under the heading "Overloading <, <=, 
 and >=".  Putting it under "Overloading == and !=" would be *better*....

Stewart.
Jul 19 2006
prev sibling next sibling parent Lucas Goss <lgoss007 gmail.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 

Thanks! Especially for breaking things (like making default imports private) to do things correctly. Lucas
Jul 19 2006
prev sibling next sibling parent Jari-Matti Mäkelä <Jari-Matti_member pathlink.com> writes:
Thanks again. The new imports look great.
Jul 19 2006
prev sibling next sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <e9jfdd$1sb0$1 digitaldaemon.com>, Walter Bright says...
http://www.digitalmars.com/d/changelog.html

This has all the new import changes in it. That breaks a lot of existing 
code (like dmdscript), the fixes are simple (adding more import 
declarations) but tedious.

I couldn't find a better keyword choice than "static import".

The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:

1) didn't want to add new keywords, especially ones like 'as' as I use 
that as a variable name

2) didn't need to add new keywords - adding them should be done only if 
using punctuation is completely unappealing

3) using '=' and ':' is visually more distinct than embedded keywords.

Walter thanks for making the imports private by default! I'm glad you finally listen on this subject. ;) Keep up the good work!! ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!" ------------------------------------------------------------------- MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Jul 19 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Nice update!

Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 

But would that require adding them as keywords? I mean, since the "as" (or whichever) appears in a specific and separate context, just as the "exit", "success" and "failure" of the scope statement, which are not keywords?
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

-- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 19 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:
 Nice update!
 
 Walter Bright wrote:
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name

But would that require adding them as keywords? I mean, since the "as" (or whichever) appears in a specific and separate context, just as the "exit", "success" and "failure" of the scope statement, which are not keywords?

Context dependent keywords are generally considered a bad idea. The scope words can never be confused with any identifiers, so I think that's not quite the same thing.
Jul 19 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
Walter Bright wrote:
 Bruno Medeiros wrote:
 
 Nice update!

 Walter Bright wrote:

 1) didn't want to add new keywords, especially ones like 'as' as I 
 use that as a variable name

But would that require adding them as keywords? I mean, since the "as" (or whichever) appears in a specific and separate context, just as the "exit", "success" and "failure" of the scope statement, which are not keywords?

Context dependent keywords are generally considered a bad idea. The scope words can never be confused with any identifiers, so I think that's not quite the same thing.

What's so bad about context dependent keywords? They're great for disambiguating confusing syntax and making it more readable: alias 'type' as 'identitifer' Now you know the order of the alias statement; it reads left to right. You don't have to force 'as' to be a real keyword and effectively disallow its use as a variable. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M-- V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++ ------END GEEK CODE BLOCK------ James Dunne
Jul 20 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
James Dunne wrote:
 What's so bad about context dependent keywords?

Then the lexer cannot tokenize the source without doing a parse. This negatively impacts tools that need to do so like Ddoc. Furthermore, it is confusing if one also has a typedef named 'as'. Having keywords be distinct, and always distinct, from identifiers means you can look at code and see what's an identifier and what's a keyword without confusion.
Jul 20 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
Walter Bright wrote:
 James Dunne wrote:
 
 What's so bad about context dependent keywords?

Then the lexer cannot tokenize the source without doing a parse. This negatively impacts tools that need to do so like Ddoc.

Sure it can. Treat 'as' as an identifier everywhere. It only has special meaning within the 'alias' statement syntax. During parsing you treat it as an identifier and check that it equates to the string 'as'. What does Ddoc need to know about keywords for? It's a function of the DMD compiler and should thus know everything DMD knows. 'as' is not a keyword, anyway. A tool designed to work with the language should implement a correct lexer and parser combination.
 Furthermore, it is confusing if one also has a typedef named 'as'. 
 Having keywords be distinct, and always distinct, from identifiers means 
 you can look at code and see what's an identifier and what's a keyword 
 without confusion.

Perfectly legal: alias int as as; int main(char[][] args) { as b; b = 2; } 'as' means nothing to the compiler outside the 'alias' statement. It goes back to the same argument as "IF THEN THEN ELSE ELSE END" -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M-- V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++ ------END GEEK CODE BLOCK------ James Dunne
Jul 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
James Dunne wrote:
 What does Ddoc need to know about keywords for?

For the color syntax highlighting of D source code.
Jul 20 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

Thanks - great release!
Jul 20 2006
prev sibling parent Carlos Santander <csantander619 gmail.com> writes:
Walter Bright escribió:
 
 http://www.digitalmars.com/d/changelog.html
 
 This has all the new import changes in it. That breaks a lot of existing 
 code (like dmdscript), the fixes are simple (adding more import 
 declarations) but tedious.
 
 I couldn't find a better keyword choice than "static import".
 
 The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
 
 1) didn't want to add new keywords, especially ones like 'as' as I use 
 that as a variable name
 
 2) didn't need to add new keywords - adding them should be done only if 
 using punctuation is completely unappealing
 
 3) using '=' and ':' is visually more distinct than embedded keywords.

A bit late from me, but thanks! -- Carlos Santander Bernal
Jul 21 2006