DMD 0.163 release

[Chris Nicholson-Sauls]

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