View previous topic :: View next topic |
Author |
Message |
Ant
Joined: 06 Mar 2004 Posts: 306 Location: Canada
|
Posted: Mon Feb 27, 2006 12:45 am Post subject: segfault - found problem |
|
|
Ok!
moving the import declaration in the class gdk.Drawable to the module level fixes the problem.
Originally all the imports on the new Duit were at the module level.
That created some problem (which I can't recall now).
I'll move the imports back the the module level and see if the original problem is solvable.
Thank you all for your help!
Specially Lars Ivar and h3r3tic!
Ant
PS did thank Lars Ivar and h3r3tic? |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Mon Feb 27, 2006 1:41 am Post subject: |
|
|
Ant, I'm glad you were able to track down these problems.
Kudo's to Lars and Tom for giving you a hand. I know they were quite busy on IRC trying to help troubleshoot the problem.
Although I didn't know that was the answer to the problem, I was checking your code last night and was surprised that you were still using all the class local imports in that DUIT module. I was planning on asking you about that but got really busy at work .
For those that want to learn from this issue:
A class local import is something that has been "available" in D for few years now, but is to be avoided at all costs. It looks like this:
Code: |
class Foo
{
private import useful.functions;
.... // rest of class definition
}
|
Doing this adds all functions/methods in the useful.functions namespace to the current class Foo namespace, such that if the useful.functions module contained theFunction(), an instantiated Foo object called "foo" would be able to treat theFunction() as one of its members, and a developer, therefore, could make a call like foo.theFunction(). It's almost like a mixin in this case.
Doing class local imports has been a major "no-no" for awhile because of the name lookup rules in D that still exist (and will likely continue to exist). Class local imports sometimes cause strange name conflicts that can go unnoticed. The compiler will not necessarily report a problem as long as the name lookup is satisfied. This can lead to "overloaded-by-local-import" methods wrongly being chosen for use by the compiler. So the cardinal rule remains: don't use class local imports unless you really, really know what you are doing; class local imports are to be avoided no matter how much one likes seeing the imports proximal to the code that uses the imported methods (an advantage, admittedly, for code readability).
Anyway, I'm glad that fixes the problem! Once again cheers to Tom and Lars for putting in the troubleshooting time with Ant. That's what teamwork is about, and I think we will be able to continue to attract Ant's expertise if we keep encouraging him with a helping hand.
Thanks guys!
- JJR
PS I'm stuck at work right now so I can't join in on the party that is likely happening right now on IRC. |
|
Back to top |
|
|
Ant
Joined: 06 Mar 2004 Posts: 306 Location: Canada
|
Posted: Mon Feb 27, 2006 10:15 am Post subject: |
|
|
JJR wrote: | Ant, I'm glad you were able to track down these problems.
...
Kudo's to Lars and Tom for giving you a hand. I know they were quite busy on IRC trying to help troubleshoot the problem.
...
Doing class local imports has been a major "no-no" for awhile because of the name lookup rules in D |
Not necessarally.
Because I allways use classes that is not a problem.
And that's why I allways use classes on D.
I create a mixin when I want that behaviour.
Allways using classes is imposed by the lookup rules in D.
If you don't use classes you will be doomed sonner or later!
I'll post a bug on the newsgroup.
Either the import on the class body should be elligal or should produce valid code.
Thank you for your help also John!
Showing interest on the problem is already a big help.
(You'll understant that if you give your time for free)
Ant |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Mon Feb 27, 2006 11:43 am Post subject: |
|
|
Ant wrote: | JJR wrote: | Ant, I'm glad you were able to track down these problems.
...
Kudo's to Lars and Tom for giving you a hand. I know they were quite busy on IRC trying to help troubleshoot the problem.
...
Doing class local imports has been a major "no-no" for awhile because of the name lookup rules in D |
Not necessarally.
Because I allways use classes that is not a problem.
And that's why I allways use classes on D.
I create a mixin when I want that behaviour. |
Good point, Ant. I failed to delineated the difference between importing modules with classes and importing modules with free functions. Importing free functions is dangerous.
Ant wrote: | Allways using classes is imposed by the lookup rules in D.
If you don't use classes you will be doomed sonner or later!
I'll post a bug on the newsgroup.
Either the import on the class body should be elligal or should produce valid code.
|
Good idea. But I wonder if Walter will bother fixing it. From what I've seen in the past, he doesn't appear to care about this problem. He just figures that the programmer shouldn't use the "feature."
Ant wrote: |
Thank you for your help also John!
Showing interest on the problem is already a big help.
(You'll understant that if you give your time for free)
|
Ah... I did nothing . Please don't thank me; I'm entirely undeserving of it. I'm just very happy that this was resolved!
-JJR |
|
Back to top |
|
|
|