A Web-based News Reader
| Subject | Re: DMD 0.163 release |
| From | Chris Nicholson-Sauls <ibisbasenji@gmail.com> |
| Date | Wed, 19 Jul 2006 03:21:44 -0500 |
| Newsgroups | digitalmars.D.announce |
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 | |
