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:


Or to do a static renamed selective import, even:

'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:



No.


 Or to do a static renamed selective import, even:

 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
    ...
 }




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
    ...
 }


 

 
 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
    ...
 }



 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