Re: static this sucks, we should deprecate it
Hello Don, BCS wrote: [...] Yes this gets into some interesting "Is is illegal code" issues but... No. The problem with that is that it's a nightmare for portability. [...] You'd have to precisely define which scenarios are allowed. If those rules were added, I'd add more rules to a compiler I built but with a command line flag to turn them on.
Re: static this sucks, we should deprecate it
BCS wrote: Hello Don, You could relax the rule: Even if modules A and B both have 'static this', there is no circular dependency if: (1) throughout the whole of module A, it only uses pure functions from module B. OR (2) if the constructor of module A doesn't directly access static variables of module B, and EVERY function it calls is pure. But that probably doesn't open up very many use cases. or (3) the compiler can prove no dependency exists. Yes this gets into some interesting "Is is illegal code" issues but... No. The problem with that is that it's a nightmare for portability. Code which will work fine on compiler A, won't compiler on compiler B. You'd have to precisely define which scenarios are allowed. The two I proposed are simple cases where it can prove no dependency exists. No doubt there are many more.
Re: static this sucks, we should deprecate it
grauzone wrote: I had the same problem when writing the D/Objective-C bridge. Basically, if you ask the Objective-C runtime to instanciate a class not previously registered, it won't find it. My choice was to require manual pre-registrations of the classes you want to use, and register everything that is possible lazily as soon as you use a bridged class. Yes, and that "pre-registration" is only there to make the compiler generate the required compile-time reflection code (like with .tupleof or __traits). While compile-time reflection is probably really more flexible than runtime reflection, requiring this kind of "registration" remains a weakness of the compile-time approach. Solutions would be to make reflection fully dynamic (as you said) and extend RTTI for that, or to provide better ways to inspect modules as a whole. For the latter, maybe __traits should just be able to inspect all members of a module, and to follow imports. Or one could introduce some kind of "module preprocessor", which enables you to execute code for each module at compile time (transparent for the processed module). Just by the way, annotations would also be nice. It's annoying to add additional information to members without them. This "additional information" can be stuff like default values, versioning of serializable members, behavior for missing values on deserialization, human readable help text if you want to use reflection to read/write user configuration files... I've seen four good uses of annotations in the past that could not easily be replaced: - dependency injection configuration - ORM configuration - event broker registration (this method should be called on this event) - test method/class registration This brings up an issue. Let's say I use static constructors to configure a serialization library, then use a static constructor to read objects using this serialization library. There's no way to define an order in which static constructors should be run within a module, but here it makes a huge difference. It would be very convenient to have as much of this configuration as possible in a readable format and not static constructors.
Re: static this sucks, we should deprecate it
I had the same problem when writing the D/Objective-C bridge. Basically, if you ask the Objective-C runtime to instanciate a class not previously registered, it won't find it. My choice was to require manual pre-registrations of the classes you want to use, and register everything that is possible lazily as soon as you use a bridged class. Yes, and that "pre-registration" is only there to make the compiler generate the required compile-time reflection code (like with .tupleof or __traits). While compile-time reflection is probably really more flexible than runtime reflection, requiring this kind of "registration" remains a weakness of the compile-time approach. Solutions would be to make reflection fully dynamic (as you said) and extend RTTI for that, or to provide better ways to inspect modules as a whole. For the latter, maybe __traits should just be able to inspect all members of a module, and to follow imports. Or one could introduce some kind of "module preprocessor", which enables you to execute code for each module at compile time (transparent for the processed module). Just by the way, annotations would also be nice. It's annoying to add additional information to members without them. This "additional information" can be stuff like default values, versioning of serializable members, behavior for missing values on deserialization, human readable help text if you want to use reflection to read/write user configuration files...
Re: static this sucks, we should deprecate it
On 2009-06-03 10:54:55 -0400, grauzone said: 3. When you want template mixins to contain a static this, your approach doesn't really work at all. The template mixin obviously can't generate a new module to move the static ctor there. As an example for real life usage, look at BCS's serialization code. (See his thread on d.D.announce, code link is on his blog post.) He uses a template mixin containing a static ctor, to make a class "known" to the serialization system. Using a template mixin with static ctor is a nice way to hide that mechanism from the user, but it disallows cyclic module dependencies. I claim that many users, who try to substitute the lacking RTTI with a custom mechanism, will hit the same problem. I had the same problem when writing the D/Objective-C bridge. Basically, if you ask the Objective-C runtime to instanciate a class not previously registered, it won't find it. My choice was to require manual pre-registrations of the classes you want to use, and register everything that is possible lazily as soon as you use a bridged class. A nice way to improve this that wouldn't require static this at all would be to have better runtime reflection in D so I could iterate over all classes and registering those implementing the ObjcObject interface using some kind of mixin-generated static functions which can be discovered at runtime. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: static this sucks, we should deprecate it
Walter Bright wrote: Jarrett Billingsley wrote: On Sun, May 31, 2009 at 4:39 PM, Walter Bright wrote: The solution is relatively robust and straightforward. Create a third module, AB. Module A and module B both import AB. Put the static constructors for both A and B in module AB. The order of initialization problem is robustly solved, and all the interdependencies of initialization of A and B are explicitly laid out in AB. If I might speak from personal experience, what usually ends up happening instead is that A and B get merged into a single module. This happens enough times, and you have half your code in one file. What is wrong with the approach I outlined? I use it, it works fine. 1. Requires more code 2. Requires additional modules (!) (as a consequence to 1+2, code is a lot less clearer to read) 3. When you want template mixins to contain a static this, your approach doesn't really work at all. The template mixin obviously can't generate a new module to move the static ctor there. As an example for real life usage, look at BCS's serialization code. (See his thread on d.D.announce, code link is on his blog post.) He uses a template mixin containing a static ctor, to make a class "known" to the serialization system. Using a template mixin with static ctor is a nice way to hide that mechanism from the user, but it disallows cyclic module dependencies. I claim that many users, who try to substitute the lacking RTTI with a custom mechanism, will hit the same problem.
Re: static this sucks, we should deprecate it
On Wed, Jun 3, 2009 at 2:56 AM, BCS wrote: > Hello Don, > >> You could relax the rule: Even if modules A and B both have 'static >> this', there is no circular dependency if: >> (1) throughout the whole of module A, it only uses pure functions from >> module B. >> OR >> (2) if the constructor of module A doesn't directly access static >> variables of module B, and EVERY function it calls is pure. >> But that probably doesn't open up very many use cases. >> > > or (3) the compiler can prove no dependency exists. Yes this gets into some > interesting "Is is illegal code" issues but... I never quite understood why it couldn't just do this already. Rarely in static this() do I access members from other modules; I'm usually creating singleton instances or initializing AAs or other such mundane tasks. Even if the compiler doesn't know whether or not other modules have a static this() (i.e. when using a .di file), it can at least tell when a given module _doesn't_ depend on others for its initialization.
Re: static this sucks, we should deprecate it
Hello Don, You could relax the rule: Even if modules A and B both have 'static this', there is no circular dependency if: (1) throughout the whole of module A, it only uses pure functions from module B. OR (2) if the constructor of module A doesn't directly access static variables of module B, and EVERY function it calls is pure. But that probably doesn't open up very many use cases. or (3) the compiler can prove no dependency exists. Yes this gets into some interesting "Is is illegal code" issues but...
Re: static this sucks, we should deprecate it
Walter Bright wrote: Christopher Wright wrote: Eh, this would have to extend to every function, since static ctors can call functions. And these functions can be provided without implementations via a .di file. This is fail. Such problems are called "whole program analysis", or "interprocedural analysis". There are a lot of cool things you can do with that, but of course they require 100% of the program text to be available to the compiler. That isn't going to happen with D (even if all the D source were available, what about calling C binaries?). So we have to rely on other mechanisms. You could relax the rule: Even if modules A and B both have 'static this', there is no circular dependency if: (1) throughout the whole of module A, it only uses pure functions from module B. OR (2) if the constructor of module A doesn't directly access static variables of module B, and EVERY function it calls is pure. But that probably doesn't open up very many use cases.
Re: static this sucks, we should deprecate it
Hello Walter, That's why, for example, airplanes have things that must be removed before flight attached to big red flags that hang outside. You don't really want to find out after you're airborne that your pitot tubes still have the dust cap on! Or even better: http://www.aircraftspruce.com/catalog/graphics/10-02000.jpg the local airport added these to it's rentals after a few aborted takeoffs (from bugs in the tubes).
Re: static this sucks, we should deprecate it
Christopher Wright wrote: Eh, this would have to extend to every function, since static ctors can call functions. And these functions can be provided without implementations via a .di file. This is fail. Such problems are called "whole program analysis", or "interprocedural analysis". There are a lot of cool things you can do with that, but of course they require 100% of the program text to be available to the compiler. That isn't going to happen with D (even if all the D source were available, what about calling C binaries?). So we have to rely on other mechanisms.
Re: static this sucks, we should deprecate it
BCS wrote: An executable that never works and fails with a resonable error message at startup is *loads* better than one that either silently runs incorrectly (generates bad results) or erratically fails. I see a *major* difference. Not just a major difference, but a fundamental one. A failure that happens obviously and repeatably is fundamentally different from a failure that goes unnoticed or is not repeatable. A basic principle of developing robust systems is to make any failures obvious. That's why, for example, airplanes have things that must be removed before flight attached to big red flags that hang outside. You don't really want to find out after you're airborne that your pitot tubes still have the dust cap on!
Re: static this sucks, we should deprecate it
Denis Koroskin wrote: Which is even worse. Walter stated that "silently generating bad code" (i.e. code that doesn't work) is a top priority bug. It fails immediately on trying to run it, it is not silently failing. Silently failing is having a dependency on the order of initialization, but not detecting it, and initializing things in the wrong order.
Re: static this sucks, we should deprecate it
Jarrett Billingsley wrote: On Sun, May 31, 2009 at 4:39 PM, Walter Bright wrote: The solution is relatively robust and straightforward. Create a third module, AB. Module A and module B both import AB. Put the static constructors for both A and B in module AB. The order of initialization problem is robustly solved, and all the interdependencies of initialization of A and B are explicitly laid out in AB. If I might speak from personal experience, what usually ends up happening instead is that A and B get merged into a single module. This happens enough times, and you have half your code in one file. What is wrong with the approach I outlined? I use it, it works fine.
Re: static this sucks, we should deprecate it
On Sun, May 31, 2009 at 4:39 PM, Walter Bright wrote: > > The solution is relatively robust and straightforward. Create a third > module, AB. Module A and module B both import AB. Put the static > constructors for both A and B in module AB. The order of initialization > problem is robustly solved, and all the interdependencies of initialization > of A and B are explicitly laid out in AB. If I might speak from personal experience, what usually ends up happening instead is that A and B get merged into a single module. This happens enough times, and you have half your code in one file. The only way to avoid this is either to create circularly-importing modules, which are considered bad practice (and also cause DMD's forward reference bugs to rear their heads), or to completely refactor your code, which is rarely an attractive option.
Re: static this sucks, we should deprecate it
Tim Matthews wrote:
Walter Bright wrote:
It's unreliable because how do you specify the load order? And how
does the user relate that to the source semantics?
grauzone suggested this earlier:
static this {} //full dependencies (all import statements)
static this : a, b {} //only dependent from module a and b
static this : void {} //no dependencies at all
Such annotations tend to get seriously out of date and wrong as code
evolves. For example, if A and B import each other:
-
--- A ---
import B;
int foo() { ... }
static this()
{
...
}
--- B ---
import A;
import C;
int x;
static this : C()
{
x = A.foo();
}
---
Now, this may work just fine, until module A gets updated at some point
in the future to depend on its static constructor. Then, B.x will get
some unpredictable value, depending on the order of initialization.
So, in general, annotations in one module that specify what happens in
another module are bad maintenance bugs waiting to happen.
The solution is relatively robust and straightforward. Create a third
module, AB. Module A and module B both import AB. Put the static
constructors for both A and B in module AB. The order of initialization
problem is robustly solved, and all the interdependencies of
initialization of A and B are explicitly laid out in AB.
Re: static this sucks, we should deprecate it
Derek Parnell wrote:
On Sat, 30 May 2009 03:52:44 +1200, Tim Matthews wrote:
Walter Bright wrote:
It's unreliable because how do you specify the load order? And how does
the user relate that to the source semantics?
grauzone suggested this earlier:
static this {} //full dependencies (all import statements)
static this : a, b {} //only dependent from module a and b
static this : void {} //no dependencies at all
Is there a situation in which the dependancies are not known by the coder
writer? For example, linking in some object code that has a "static this{}"
section and not having the source code for that object code.
file A.di:
void foo();
file B.d:
static this () { foo(); }
All bets are off. A more sophisticated object format can correct this.
Re: static this sucks, we should deprecate it
On Sat, 30 May 2009 03:52:44 +1200, Tim Matthews wrote:
> Walter Bright wrote:
>
>>
>> It's unreliable because how do you specify the load order? And how does
>> the user relate that to the source semantics?
>
> grauzone suggested this earlier:
>
> static this {} //full dependencies (all import statements)
> static this : a, b {} //only dependent from module a and b
> static this : void {} //no dependencies at all
Is there a situation in which the dependancies are not known by the coder
writer? For example, linking in some object code that has a "static this{}"
section and not having the source code for that object code.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: static this sucks, we should deprecate it
Walter Bright wrote:
It's unreliable because how do you specify the load order? And how does
the user relate that to the source semantics?
grauzone suggested this earlier:
static this {} //full dependencies (all import statements)
static this : a, b {} //only dependent from module a and b
static this : void {} //no dependencies at all
Re: static this sucks, we should deprecate it
Christopher Wright wrote: The compiler could examine the symbols used in the static constructors to build these dependency lists. Eh, this would have to extend to every function, since static ctors can call functions. And these functions can be provided without implementations via a .di file. This is fail.
Re: static this sucks, we should deprecate it
Robert Fraser wrote: Walter Bright wrote: Ary Borenszweig wrote: The thing is, I've been using Java for more than 7 years now and I never got any error because of intialization dependency. It would be nice to turn that check off in D and see the results. Maybe no one will complain about it. Eliminating implementation-defined behavior like that makes a language more reliable and portable. Java's failure to address this is a hole in their system. It's not implementation-defined. When a class is loaded (the times at which it is are specified), static members are initialized and static blocks run in the order that they appear in the source file. It's unreliable because how do you specify the load order? And how does the user relate that to the source semantics?
Re: static this sucks, we should deprecate it
Unknown W. Brackets wrote:
Because you've never tried to use data initialized circularly. I wonder
what would happen in Java if you did?
-[Unknown]
Frank Benoit wrote:
Unknown W. Brackets schrieb:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems stem
from either wrong order or co-dependence (which needs to be solved by
the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
In Java the
static { /* static ctor code */ }
does not have the circular dependency problem. why is that?
It gives a compile-time error message.
Re: static this sucks, we should deprecate it
Walter Bright wrote: Ary Borenszweig wrote: The thing is, I've been using Java for more than 7 years now and I never got any error because of intialization dependency. It would be nice to turn that check off in D and see the results. Maybe no one will complain about it. Eliminating implementation-defined behavior like that makes a language more reliable and portable. Java's failure to address this is a hole in their system. It's not implementation-defined. When a class is loaded (the times at which it is are specified), static members are initialized and static blocks run in the order that they appear in the source file.
Re: static this sucks, we should deprecate it
Because you've never tried to use data initialized circularly. I wonder
what would happen in Java if you did?
-[Unknown]
Frank Benoit wrote:
Unknown W. Brackets schrieb:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems stem
from either wrong order or co-dependence (which needs to be solved by
the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
In Java the
static { /* static ctor code */ }
does not have the circular dependency problem. why is that?
Re: static this sucks, we should deprecate it
Actually, I didn't put that much thought into it. I see what you're
saying. If you leave them off, it has to behave as now (otherwise it
would break backwards compatibility.)
-[Unknown]
grauzone wrote:
static this as OP said not so good. Why would you need to specify no
dependencies? The way it works now is not ambiguous and wouldn't
conflict with the dependencies syntax.
Because if you really have no dependency, you had to specify a dummy
module.
As I understand, Mr. Bracket's proposal works as this:
static this {} //full dependencies (all import statements)
static this : a, b {} //only dependent from module a and b
And I'd add
static this : void {} //no dependencies at all
Re: static this sucks, we should deprecate it
Ary Borenszweig wrote: The thing is, I've been using Java for more than 7 years now and I never got any error because of intialization dependency. It would be nice to turn that check off in D and see the results. Maybe no one will complain about it. Eliminating implementation-defined behavior like that makes a language more reliable and portable. Java's failure to address this is a hole in their system.
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 21:41:01 -0400, Ary Borenszweig
wrote:
The thing is, I've been using Java for more than 7 years now and I never
got any error because of intialization dependency. It would be nice to
turn that check off in D and see the results. Maybe no one will complain
about it.
(Or maybe it was added because someone complained about it, some years
ago? I don't know...)
You are probably right that most of the time static initializers do not
depend on external variables. But it might be best to start with the
conservative option and move towards the compromise than the other way
around. I think a reasonable first step is to implement some better
runtime checks.
For example, the compiler could put wrappers around static this calls:
_wrapper()
{
// mode is initted to 0 by the runtime.
static int mode;
if(mode == 0)
{
mode = 1;
static_this(); // calls the static initializers of the module
mode = 2;
}
else if(mode == 1) // a dependency of this module called this module's
initializer!
{
assert(false, "circular dependency!");
}
}
And put calls to a dependent module's _wrapper function in other modules
when they are about to access static variables in that other module.
for example:
f1.d:
import f2;
int x;
int n;
static this()
{
n = 4;
x = y;
}
f2.d:
import f1;
int y;
static this()
{
y = 5;
}
f1.d's static this becomes:
static this()
{
f2._wrapper();
x = y;
}
and f2.d's static this remains the same because it doesn't have any
dependencies. Then the compiler can call the static initializers in any
order, and they do the right thing.
This still wouldn't be perfect, because you may get incorrect assertions,
but it's better than what we have now.
-Steve
Re: static this sucks, we should deprecate it
Steven Schveighoffer escribió:
On Thu, 28 May 2009 17:37:57 -0400, Ary Borenszweig
wrote:
Frank Benoit escribió:
Unknown W. Brackets schrieb:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems
stem
from either wrong order or co-dependence (which needs to be solved by
the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
In Java the
static { /* static ctor code */ }
does not have the circular dependency problem. why is that?
Consider this:
class A {
public static int x;
static {
x = B.x + 10;
}
public static void main(String[] args) {
System.out.println("A.x = " + A.x);
System.out.println("B.x = " + B.y);
}
}
class B {
public static int y;
static {
y = A.x + 10;
}
public static void main(String[] args) {
System.out.println("A.x = " + A.x);
System.out.println("B.x = " + B.y);
}
}
If you run A, you'll get:
A.x = 20
B.x = 10
If you run B, you'll get:
A.x = 10
B.x = 20
That's because the static { } is run when the class is first loaded.
So in a sense there is the problem is circular dependency: depending
on the order of class loading you get different results.
Is this the problem being discussed, how to define the order of static
this?
Yes.
So Java basically allows the circular dependency because it assumes you
know what you are doing :) That could be even worse than the D solution!
However, I think this could be solved in Java more readily than it could
be in D...
The thing is, I've been using Java for more than 7 years now and I never
got any error because of intialization dependency. It would be nice to
turn that check off in D and see the results. Maybe no one will complain
about it.
(Or maybe it was added because someone complained about it, some years
ago? I don't know...)
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 17:37:57 -0400, Ary Borenszweig
wrote:
Frank Benoit escribió:
Unknown W. Brackets schrieb:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems
stem
from either wrong order or co-dependence (which needs to be solved by
the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
In Java the
static { /* static ctor code */ }
does not have the circular dependency problem. why is that?
Consider this:
class A {
public static int x;
static {
x = B.x + 10;
}
public static void main(String[] args) {
System.out.println("A.x = " + A.x);
System.out.println("B.x = " + B.y);
}
}
class B {
public static int y;
static {
y = A.x + 10;
}
public static void main(String[] args) {
System.out.println("A.x = " + A.x);
System.out.println("B.x = " + B.y);
}
}
If you run A, you'll get:
A.x = 20
B.x = 10
If you run B, you'll get:
A.x = 10
B.x = 20
That's because the static { } is run when the class is first loaded.
So in a sense there is the problem is circular dependency: depending on
the order of class loading you get different results.
Is this the problem being discussed, how to define the order of static
this?
Yes.
So Java basically allows the circular dependency because it assumes you
know what you are doing :) That could be even worse than the D solution!
However, I think this could be solved in Java more readily than it could
be in D...
-Steve
Re: static this sucks, we should deprecate it
Steven Schveighoffer wrote: On Thu, 28 May 2009 13:59:10 -0400, Ary Borenszweig wrote: Is there something wrong in my reasoning? It's just that you aren't always compiling every file at the same time... Static this' implementation isn't part of the public interface, so it might not even *be* in the import file (if it's a .di file). Where do you throw the compiler error, if you can't determine the circular reference at comiple time? I think with the import system the way it is, the only safe prospect is to have it error like it does now. You either need some attribution like has been suggested in this thread (and have the compiler verify that attribution), or change the import system. The compiler could examine the symbols used in the static constructors to build these dependency lists. Then it's a matter of assembling a graph and checking for cycles. Each ModuleInfo would reference the modules its static constructors depend on in addition to the ones it imports. This would be used by the runtime to determine the proper order in which to call static constructors. As a first step, the compiler could mark a module as having static constructors. Then the cycle detection could happen at compile time rather than runtime. The sooner you detect errors, the better.
Re: static this sucks, we should deprecate it
Frank Benoit escribió:
Unknown W. Brackets schrieb:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems stem
from either wrong order or co-dependence (which needs to be solved by
the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
In Java the
static { /* static ctor code */ }
does not have the circular dependency problem. why is that?
Consider this:
class A {
public static int x;
static {
x = B.x + 10;
}
public static void main(String[] args) {
System.out.println("A.x = " + A.x);
System.out.println("B.x = " + B.y);
}
}
class B {
public static int y;
static {
y = A.x + 10;
}
public static void main(String[] args) {
System.out.println("A.x = " + A.x);
System.out.println("B.x = " + B.y);
}
}
If you run A, you'll get:
A.x = 20
B.x = 10
If you run B, you'll get:
A.x = 10
B.x = 20
That's because the static { } is run when the class is first loaded.
So in a sense there is the problem is circular dependency: depending on
the order of class loading you get different results.
Is this the problem being discussed, how to define the order of static this?
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 15:02:06 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer wrote:
On Thu, 28 May 2009 14:23:48 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer wrote:
On Thu, 28 May 2009 13:59:10 -0400, Ary Borenszweig
wrote:
Is there something wrong in my reasoning?
It's just that you aren't always compiling every file at the same
time...
Static this' implementation isn't part of the public interface, so it
might not even *be* in the import file (if it's a .di file).
So it should be in the .di file.
Where do
you throw the compiler error, if you can't determine the circular
reference at comiple time?
You don't throw the error and that's it. What's the worse thing that
could happen? A bug in the code. You go and you fix it. If there's no
bug in the code and the compiler yells at you, that's very annonying
(like in the example you showed).
A bug like this could be very subtle, you may not know the order
static this' are executed. Worse than that, simply importing another
module could affect the order, and that might make an unrelated bug
that previously was hidden suddenly show up.
I think with the import system the way it is, the only safe prospect
is to have it error like it does now. You either need some
attribution like has been suggested in this thread (and have the
compiler verify that attribution), or change the import system.
I still can't see what's the problem if the error were not issued by
the compiler and static this would be run in the order defined by
dependencies found in static ifs.
I assume you mean static this'?
Yes. :-P
Until I see a real example where if the compiler doesn't issue an
error then something *really bad* would happen, then I won't be able
to give much more opinion about this. :-(
What about this (bear with me, lots of files here):
f1.d:
private import f2;
int x;
static this()
{
x = y;
}
f2.d:
private import f3;
int y;
static this()
{
y = z;
}
f3.d:
private import f1;
int z;
static this()
{
z = x;
}
Now, the compiler has to obey 3 rules: f1 depends on f2, f2 depends on
f3, f3 depends on f1.
Oops, there's a cycle, but we can detect that, right?
What if you are importing .di files:
f2.di:
int y;
static this();
Now, how do you know when compiling f1 that it depends on f3, and f3
depends on f1? The cycle is hidden because the compiler can't look at
the compiled end result for each source file.
This is similar to the "how come the compiler can't automatically
decide what's const and what's not" debate. Unless the compiler is
allowed to generate metadata from files that it can feed back into
itself later, these kinds of things are impossible without manual
annotation.
I realize the end result of my example is pretty innocuous, but
imagine that you are trying to use an object you expect to be
instantiated by a static this function, only to find that it's null.
I'd rather see a "circular import" error than a segfault that all of a
sudden shows up because someone used my library differently.
Thanks for the example.
That's why I suggest that di files should contain the code of the static
this. Some functions in di files include their source code (I don't know
what's that rule, but I just tried it and it did it), and this might not
be important, but static this are important...
.di files are not always auto-generated. They can be hand-edited to
remove implementation (druntime's object.di is such a file).
The only problem left I see is how the compiler defines the order of
execution of static this. If there are no circularities then there's no
problem. If there is circularity, then it might be caught by the logic I
proposed. If it isn't caught at this point, and, as you said, there's a
bug and you'd get a segfault, then you'd get it as soon as you run your
code, which is exactly the same logic as now, but it gives programmers
more freedom to write their code as they want.
A segfault might not be the result. Imagine an object constructor that
uses another object, but if you pass in null it does something else
besides segfaulting.
-Steve
Re: static this sucks, we should deprecate it
Steven Schveighoffer wrote:
On Thu, 28 May 2009 08:14:45 -0400, Frank Benoit
wrote:
Unknown W. Brackets schrieb:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems stem
from either wrong order or co-dependence (which needs to be solved by
the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
In Java the
static { /* static ctor code */ }
does not have the circular dependency problem. why is that?
Probably because Java doesn't use source code as imports. It is one
flaw of D that I really wish could be fixed.
-Steve
That's not strictly true; a .java file is the compilation unit, which
can contain any number of classes (only one public, but any # of
inner/package-protected ones).
Re: static this sucks, we should deprecate it
BCS wrote: Hello Steven, On Thu, 28 May 2009 11:39:28 -0400, Matti Niemenmaa wrote: Steven Schveighoffer wrote: If we were importing compiled files (or even generated files), then the compiled file could have annotated the "static this" with the dependencies it has... I don't want to start another long thread on this, I understand Walter's "I want to use standard linkers" position. I don't think that's an argument against this; you can always compile both an intermediate representation for purposes such as these in addition to the standard object file. It's what the Haskell compiler GHC does, for instance. As long as it's part of a system where you can't accidentally use stale files, then I'd agree. The best scenario would be to import the object file directly IMO. How about serialized the AST that goes into a .di file into a special section of he object file and then suck it back in for imports? (BTW this is a solution I can live with. :) vote -= pow(MATH_E, 1.0i * MATH_PI);
Re: static this sucks, we should deprecate it
Steven Schveighoffer wrote:
On Thu, 28 May 2009 14:23:48 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer wrote:
On Thu, 28 May 2009 13:59:10 -0400, Ary Borenszweig
wrote:
Is there something wrong in my reasoning?
It's just that you aren't always compiling every file at the same
time...
Static this' implementation isn't part of the public interface, so it
might not even *be* in the import file (if it's a .di file).
So it should be in the .di file.
Where do
you throw the compiler error, if you can't determine the circular
reference at comiple time?
You don't throw the error and that's it. What's the worse thing that
could happen? A bug in the code. You go and you fix it. If there's no
bug in the code and the compiler yells at you, that's very annonying
(like in the example you showed).
A bug like this could be very subtle, you may not know the order static
this' are executed. Worse than that, simply importing another module
could affect the order, and that might make an unrelated bug that
previously was hidden suddenly show up.
I think with the import system the way it is, the only safe prospect
is to have it error like it does now. You either need some
attribution like has been suggested in this thread (and have the
compiler verify that attribution), or change the import system.
I still can't see what's the problem if the error were not issued by
the compiler and static this would be run in the order defined by
dependencies found in static ifs.
I assume you mean static this'?
Yes. :-P
Until I see a real example where if the compiler doesn't issue an
error then something *really bad* would happen, then I won't be able
to give much more opinion about this. :-(
What about this (bear with me, lots of files here):
f1.d:
private import f2;
int x;
static this()
{
x = y;
}
f2.d:
private import f3;
int y;
static this()
{
y = z;
}
f3.d:
private import f1;
int z;
static this()
{
z = x;
}
Now, the compiler has to obey 3 rules: f1 depends on f2, f2 depends on
f3, f3 depends on f1.
Oops, there's a cycle, but we can detect that, right?
What if you are importing .di files:
f2.di:
int y;
static this();
Now, how do you know when compiling f1 that it depends on f3, and f3
depends on f1? The cycle is hidden because the compiler can't look at
the compiled end result for each source file.
This is similar to the "how come the compiler can't automatically decide
what's const and what's not" debate. Unless the compiler is allowed to
generate metadata from files that it can feed back into itself later,
these kinds of things are impossible without manual annotation.
I realize the end result of my example is pretty innocuous, but imagine
that you are trying to use an object you expect to be instantiated by a
static this function, only to find that it's null.
I'd rather see a "circular import" error than a segfault that all of a
sudden shows up because someone used my library differently.
Thanks for the example.
That's why I suggest that di files should contain the code of the static
this. Some functions in di files include their source code (I don't know
what's that rule, but I just tried it and it did it), and this might not
be important, but static this are important...
The only problem left I see is how the compiler defines the order of
execution of static this. If there are no circularities then there's no
problem. If there is circularity, then it might be caught by the logic I
proposed. If it isn't caught at this point, and, as you said, there's a
bug and you'd get a segfault, then you'd get it as soon as you run your
code, which is exactly the same logic as now, but it gives programmers
more freedom to write their code as they want.
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 14:23:48 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer wrote:
On Thu, 28 May 2009 13:59:10 -0400, Ary Borenszweig
wrote:
Is there something wrong in my reasoning?
It's just that you aren't always compiling every file at the same
time...
Static this' implementation isn't part of the public interface, so it
might not even *be* in the import file (if it's a .di file).
So it should be in the .di file.
Where do
you throw the compiler error, if you can't determine the circular
reference at comiple time?
You don't throw the error and that's it. What's the worse thing that
could happen? A bug in the code. You go and you fix it. If there's no
bug in the code and the compiler yells at you, that's very annonying
(like in the example you showed).
A bug like this could be very subtle, you may not know the order static
this' are executed. Worse than that, simply importing another module
could affect the order, and that might make an unrelated bug that
previously was hidden suddenly show up.
I think with the import system the way it is, the only safe prospect
is to have it error like it does now. You either need some attribution
like has been suggested in this thread (and have the compiler verify
that attribution), or change the import system.
I still can't see what's the problem if the error were not issued by the
compiler and static this would be run in the order defined by
dependencies found in static ifs.
I assume you mean static this'?
Until I see a real example where if the compiler doesn't issue an error
then something *really bad* would happen, then I won't be able to give
much more opinion about this. :-(
What about this (bear with me, lots of files here):
f1.d:
private import f2;
int x;
static this()
{
x = y;
}
f2.d:
private import f3;
int y;
static this()
{
y = z;
}
f3.d:
private import f1;
int z;
static this()
{
z = x;
}
Now, the compiler has to obey 3 rules: f1 depends on f2, f2 depends on f3,
f3 depends on f1.
Oops, there's a cycle, but we can detect that, right?
What if you are importing .di files:
f2.di:
int y;
static this();
Now, how do you know when compiling f1 that it depends on f3, and f3
depends on f1? The cycle is hidden because the compiler can't look at the
compiled end result for each source file.
This is similar to the "how come the compiler can't automatically decide
what's const and what's not" debate. Unless the compiler is allowed to
generate metadata from files that it can feed back into itself later,
these kinds of things are impossible without manual annotation.
I realize the end result of my example is pretty innocuous, but imagine
that you are trying to use an object you expect to be instantiated by a
static this function, only to find that it's null.
I'd rather see a "circular import" error than a segfault that all of a
sudden shows up because someone used my library differently.
-Steve
Re: static this sucks, we should deprecate it
Steven Schveighoffer wrote: On Thu, 28 May 2009 13:59:10 -0400, Ary Borenszweig wrote: Is there something wrong in my reasoning? It's just that you aren't always compiling every file at the same time... Static this' implementation isn't part of the public interface, so it might not even *be* in the import file (if it's a .di file). So it should be in the .di file. Where do you throw the compiler error, if you can't determine the circular reference at comiple time? You don't throw the error and that's it. What's the worse thing that could happen? A bug in the code. You go and you fix it. If there's no bug in the code and the compiler yells at you, that's very annonying (like in the example you showed). I think with the import system the way it is, the only safe prospect is to have it error like it does now. You either need some attribution like has been suggested in this thread (and have the compiler verify that attribution), or change the import system. I still can't see what's the problem if the error were not issued by the compiler and static this would be run in the order defined by dependencies found in static ifs. Until I see a real example where if the compiler doesn't issue an error then something *really bad* would happen, then I won't be able to give much more opinion about this. :-(
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 13:59:10 -0400, Ary Borenszweig wrote: Is there something wrong in my reasoning? It's just that you aren't always compiling every file at the same time... Static this' implementation isn't part of the public interface, so it might not even *be* in the import file (if it's a .di file). Where do you throw the compiler error, if you can't determine the circular reference at comiple time? I think with the import system the way it is, the only safe prospect is to have it error like it does now. You either need some attribution like has been suggested in this thread (and have the compiler verify that attribution), or change the import system. -Steve
Re: static this sucks, we should deprecate it
Steven Schveighoffer wrote:
On Thu, 28 May 2009 12:11:18 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer wrote:
On Thu, 28 May 2009 11:32:19 -0400, Ary Borenszweig
wrote:
Unknown W. Brackets wrote:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main
problems stem from either wrong order or co-dependence (which needs
to be solved by the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could
ignore it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
davidl wrote:
Why on earth we still let the tumor grow?
I would love to specify the order by myself not by the arbitrary
order
generated by the compiler.
Hi,
Can someone explain me what is exactly the problems with static
this? Something like a small example that shows the problem, so I
can at least think of a solution (because I don't know the problem).
Thanks!
Ary
Something like:
file1.d:
import file2.d;
static this()
{
}
file2.d:
import file1.d;
static this()
{
}
fails to compile due to the perceived circular dependency, even
though none exists.
Thanks, yes, it fails to run. But why? What could happen if that error
wasn't issued? I'm looking for an example where something wrong could
happen.
I gave you the case which *should* compile, here is a case Walter is
trying to prevent:
file1.d:
import file2;
int x;
static this()
{
x = y;
}
file2.d:
int y;
static this()
{
y = x;
}
This is an obvious case, it doesn't take much imagination to envision
one that's not so obvious.
I'm starting to understand the problem. In this example I think I can
describe better the real problem:
file1.d:
import file2;
int x;
static this() {
x = y + 10;
}
file2:d
int y;
static this() {
y = 20;
}
In this case the programmer expects y to be 20, and x to be 30 (since
file1 references file2, it expects to run the static this of file2
first). And this one compiles fine because file2 doesn't import file1.
As soon as file2 imports file1, you get the error, *even though no
symbol of file1 that is referenced in a file1's static this has been
referenced in file2's static this*.
Isn't this the real problem? For this solution the compiler should
maintain references to modules only if they are referenced in the static
if's, so for this example it would be:
file1 -> { file2 }
file2 -> {}
so there's no circularity. For your example it would be:
file1 -> { file2 }
file2 -> { file1 }
and there's a circularity, and you get a *compile* error (I think this
will always be a real error).
Of course this gets complicated if the static this invokes functions,
maybe it creates instances of classes, cast them to interfaces or to
base classes, and then invoke some method and now you can't tell which
variables are referenced. But I can't truly imagine a case where this
will be a problem. And if it is, then there's something wrong in your
initialization logic, that is, a bug, and you should fix it. But most of
the time, I think, there won't be problems.
Is there something wrong in my reasoning?
Re: static this sucks, we should deprecate it
Reply to Denis, That's *exactly* the same as silently generating bad executable. You run it and get "Executable is corrupted" message (or something like this). An executable that never works and fails with a resonable error message at startup is *loads* better than one that either silently runs incorrectly (generates bad results) or erratically fails. I see a *major* difference.
Re: static this sucks, we should deprecate it
Ary Borenszweig schrieb:
> Steven Schveighoffer wrote:
>> On Thu, 28 May 2009 11:32:19 -0400, Ary Borenszweig
>> wrote:
>>
>>> Unknown W. Brackets wrote:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems
stem from either wrong order or co-dependence (which needs to be
solved by the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could
ignore it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
davidl wrote:
> Why on earth we still let the tumor grow?
> I would love to specify the order by myself not by the arbitrary order
> generated by the compiler.
>
>>>
>>> Hi,
>>>
>>> Can someone explain me what is exactly the problems with static this?
>>> Something like a small example that shows the problem, so I can at
>>> least think of a solution (because I don't know the problem).
>>>
>>> Thanks!
>>> Ary
>>
>>
>> Something like:
>>
>> file1.d:
>>
>> import file2.d;
>>
>> static this()
>> {
>> }
>>
>> file2.d:
>>
>> import file1.d;
>>
>> static this()
>> {
>> }
>>
>> fails to compile due to the perceived circular dependency, even though
>> none exists.
>
> Thanks, yes, it fails to run. But why? What could happen if that error
> wasn't issued? I'm looking for an example where something wrong could
> happen.
If that error would be generated, there would be no other way to prevent
you from accessing another module which is not yet initialized (static
this not yet run).
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 12:11:18 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer wrote:
On Thu, 28 May 2009 11:32:19 -0400, Ary Borenszweig
wrote:
Unknown W. Brackets wrote:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems
stem from either wrong order or co-dependence (which needs to be
solved by the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could
ignore it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
davidl wrote:
Why on earth we still let the tumor grow?
I would love to specify the order by myself not by the arbitrary
order
generated by the compiler.
Hi,
Can someone explain me what is exactly the problems with static this?
Something like a small example that shows the problem, so I can at
least think of a solution (because I don't know the problem).
Thanks!
Ary
Something like:
file1.d:
import file2.d;
static this()
{
}
file2.d:
import file1.d;
static this()
{
}
fails to compile due to the perceived circular dependency, even though
none exists.
Thanks, yes, it fails to run. But why? What could happen if that error
wasn't issued? I'm looking for an example where something wrong could
happen.
I gave you the case which *should* compile, here is a case Walter is
trying to prevent:
file1.d:
import file2;
int x;
static this()
{
x = y;
}
file2.d:
int y;
static this()
{
y = x;
}
This is an obvious case, it doesn't take much imagination to envision one
that's not so obvious.
-Steve
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 12:13:01 -0400, Denis Koroskin <2kor...@gmail.com> wrote: On Thu, 28 May 2009 20:00:43 +0400, BCS wrote: Hello Denis, On Thu, 28 May 2009 19:44:42 +0400, BCS wrote: Hello Steven, fails to compile due to the perceived circular dependency, even though none exists. IIRC it compiles, but fails as soon as you run it. -Steve Which is even worse. Walter stated that "silently generating bad code" (i.e. code that doesn't work) is a top priority bug. I wonder why this design flaw isn't fixed for so long... It's not silent. It fails loudly, reliably and immediately. The only way it can slip thought is if you don't even TRY to run the exe before you ship. Generating code has nothing to do with running it (unless compiler automatically runs compiled executable before returning 0) As far as DMD is concerned, is does silently generate a binary that doesn't work (and yes, you notice it immediately when you run it). That's *exactly* the same as silently generating bad executable. You run it and get "Executable is corrupted" message (or something like this). I don't believe it can be used as an excuse for not fixing this bug. You are misinterpreting Walter's statements. He wants the compiler not to generate silent errors. That is, errors which do not show up during a normal build/test process, mostly because of unexpected changes in the compiler interpretation of source files (e.g. hijacking). I don't think he meant that he wants the compiler not to generate code that was erroneously designed, or could have been erroneously designed, especially if the result is a deterministically immediate crash. For all practical purposes, running the executable is a part of the build process. You are a fool if you ship untested code simply because it compiles. This argument you are having has nothing to do with the problem at hand. The reason this hasn't been fixed is because it's not easy to do without redesigning how D imports work. It's not simply a "bug". -Steve
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 20:00:43 +0400, BCS wrote: > Hello Denis, > >> On Thu, 28 May 2009 19:44:42 +0400, BCS wrote: >> >>> Hello Steven, >>> fails to compile due to the perceived circular dependency, even though none exists. >>> IIRC it compiles, but fails as soon as you run it. >>> -Steve >> Which is even worse. Walter stated that "silently generating bad code" >> (i.e. code that doesn't work) is a top priority bug. >> I wonder why this design flaw isn't fixed for so long... >> > > It's not silent. It fails loudly, reliably and immediately. The only way > it can slip thought is if you don't even TRY to run the exe before you > ship. > > Generating code has nothing to do with running it (unless compiler automatically runs compiled executable before returning 0) As far as DMD is concerned, is does silently generate a binary that doesn't work (and yes, you notice it immediately when you run it). That's *exactly* the same as silently generating bad executable. You run it and get "Executable is corrupted" message (or something like this). I don't believe it can be used as an excuse for not fixing this bug.
Re: static this sucks, we should deprecate it
Steven Schveighoffer wrote:
On Thu, 28 May 2009 11:32:19 -0400, Ary Borenszweig
wrote:
Unknown W. Brackets wrote:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems
stem from either wrong order or co-dependence (which needs to be
solved by the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could
ignore it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
davidl wrote:
Why on earth we still let the tumor grow?
I would love to specify the order by myself not by the arbitrary order
generated by the compiler.
Hi,
Can someone explain me what is exactly the problems with static this?
Something like a small example that shows the problem, so I can at
least think of a solution (because I don't know the problem).
Thanks!
Ary
Something like:
file1.d:
import file2.d;
static this()
{
}
file2.d:
import file1.d;
static this()
{
}
fails to compile due to the perceived circular dependency, even though
none exists.
Thanks, yes, it fails to run. But why? What could happen if that error
wasn't issued? I'm looking for an example where something wrong could
happen.
Re: static this sucks, we should deprecate it
Hello Denis, On Thu, 28 May 2009 19:44:42 +0400, BCS wrote: Hello Steven, fails to compile due to the perceived circular dependency, even though none exists. IIRC it compiles, but fails as soon as you run it. -Steve Which is even worse. Walter stated that "silently generating bad code" (i.e. code that doesn't work) is a top priority bug. I wonder why this design flaw isn't fixed for so long... It's not silent. It fails loudly, reliably and immediately. The only way it can slip thought is if you don't even TRY to run the exe before you ship.
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 11:52:20 -0400, Denis Koroskin <2kor...@gmail.com> wrote: On Thu, 28 May 2009 19:44:42 +0400, BCS wrote: Hello Steven, fails to compile due to the perceived circular dependency, even though none exists. IIRC it compiles, but fails as soon as you run it. -Steve Which is even worse. Walter stated that "silently generating bad code" (i.e. code that doesn't work) is a top priority bug. I wonder why this design flaw isn't fixed for so long... It's not so silent. The code deterministically fails every time you run it. When was the last time you published a compiled program that you never tested, even once? ;) BCS, thanks for pointing that out. I forgot about that. -Steve
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 19:44:42 +0400, BCS wrote: > Hello Steven, > >> fails to compile due to the perceived circular dependency, even though >> none exists. > > IIRC it compiles, but fails as soon as you run it. > >> -Steve >> > > Which is even worse. Walter stated that "silently generating bad code" (i.e. code that doesn't work) is a top priority bug. I wonder why this design flaw isn't fixed for so long...
Re: static this sucks, we should deprecate it
Hello Steven, On Thu, 28 May 2009 11:39:28 -0400, Matti Niemenmaa wrote: Steven Schveighoffer wrote: If we were importing compiled files (or even generated files), then the compiled file could have annotated the "static this" with the dependencies it has... I don't want to start another long thread on this, I understand Walter's "I want to use standard linkers" position. I don't think that's an argument against this; you can always compile both an intermediate representation for purposes such as these in addition to the standard object file. It's what the Haskell compiler GHC does, for instance. As long as it's part of a system where you can't accidentally use stale files, then I'd agree. The best scenario would be to import the object file directly IMO. How about serialized the AST that goes into a .di file into a special section of he object file and then suck it back in for imports? (BTW this is a solution I can live with. :)
Re: static this sucks, we should deprecate it
On Thu, May 28, 2009 at 11:41:36AM -0400, Steven Schveighoffer wrote: > As long as it's part of a system where you can't accidentally use stale > files, then I'd agree. The best scenario would be to import the object > file directly IMO. Is there a comments field or something in the object file format that we could use to stick the source code into? Then, you could read the source used to compile the object from that field, checking for stale versions, while not affecting how the linker itself works. > > -Steve -- Adam D. Ruppe http://arsdnet.net
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 11:39:28 -0400, Matti Niemenmaa wrote: Steven Schveighoffer wrote: If we were importing compiled files (or even generated files), then the compiled file could have annotated the "static this" with the dependencies it has... I don't want to start another long thread on this, I understand Walter's "I want to use standard linkers" position. I don't think that's an argument against this; you can always compile both an intermediate representation for purposes such as these in addition to the standard object file. It's what the Haskell compiler GHC does, for instance. As long as it's part of a system where you can't accidentally use stale files, then I'd agree. The best scenario would be to import the object file directly IMO. -Steve
Re: static this sucks, we should deprecate it
Hello Steven, fails to compile due to the perceived circular dependency, even though none exists. IIRC it compiles, but fails as soon as you run it. -Steve
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 11:36:23 -0400, Steven Schveighoffer
wrote:
On Thu, 28 May 2009 11:32:19 -0400, Ary Borenszweig
wrote:
Unknown W. Brackets wrote:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems
stem from either wrong order or co-dependence (which needs to be
solved by the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
davidl wrote:
Why on earth we still let the tumor grow?
I would love to specify the order by myself not by the arbitrary order
generated by the compiler.
Hi,
Can someone explain me what is exactly the problems with static this?
Something like a small example that shows the problem, so I can at
least think of a solution (because I don't know the problem).
Thanks!
Ary
Something like:
file1.d:
import file2.d;
static this()
{
}
file2.d:
import file1.d;
static this()
{
}
fails to compile due to the perceived circular dependency, even though
none exists.
-Steve
Um.. duh, I meant:
import file1;
not import file1.d;
With that fix, then you should get the right message :)
-Steve
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 11:32:19 -0400, Ary Borenszweig
wrote:
Unknown W. Brackets wrote:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems
stem from either wrong order or co-dependence (which needs to be solved
by the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
davidl wrote:
Why on earth we still let the tumor grow?
I would love to specify the order by myself not by the arbitrary order
generated by the compiler.
Hi,
Can someone explain me what is exactly the problems with static this?
Something like a small example that shows the problem, so I can at least
think of a solution (because I don't know the problem).
Thanks!
Ary
Something like:
file1.d:
import file2.d;
static this()
{
}
file2.d:
import file1.d;
static this()
{
}
fails to compile due to the perceived circular dependency, even though
none exists.
-Steve
Re: static this sucks, we should deprecate it
Steven Schveighoffer wrote: If we were importing compiled files (or even generated files), then the compiled file could have annotated the "static this" with the dependencies it has... I don't want to start another long thread on this, I understand Walter's "I want to use standard linkers" position. I don't think that's an argument against this; you can always compile both an intermediate representation for purposes such as these in addition to the standard object file. It's what the Haskell compiler GHC does, for instance. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 11:07:02 -0400, BCS wrote: Hello Steven, Probably because Java doesn't use source code as imports. It is one flaw of D that I really wish could be fixed. Here we go again! I don't (and won't, so don't try explaining it) understand why people think file=module is a flaw, I LIKE the idea. The flaw isn't that file=module. the flaw is that uncompiled-file=import. When you are importing source files, and then linking them to object files that could have been compiled from different sources, you run the risk of hard-to-find bugs, and weird crashes (and not being able to detect cycles!). It is one of the things I didn't like about source/header separation in C/C++. D gets one step closer by having the implementation and header in one file, but you still are importing the source file, which means you have to compile it during import just to understand what it means. If we were importing compiled files (or even generated files), then the compiled file could have annotated the "static this" with the dependencies it has... I don't want to start another long thread on this, I understand Walter's "I want to use standard linkers" position. But this is the explanation I think for Java being able to succeed where D cannot. -Steve
Re: static this sucks, we should deprecate it
Unknown W. Brackets wrote:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems stem
from either wrong order or co-dependence (which needs to be solved by
the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
davidl wrote:
Why on earth we still let the tumor grow?
I would love to specify the order by myself not by the arbitrary order
generated by the compiler.
Hi,
Can someone explain me what is exactly the problems with static this?
Something like a small example that shows the problem, so I can at least
think of a solution (because I don't know the problem).
Thanks!
Ary
Re: static this sucks, we should deprecate it
Hello Steven, Probably because Java doesn't use source code as imports. It is one flaw of D that I really wish could be fixed. Here we go again! I don't (and won't, so don't try explaining it) understand why people think file=module is a flaw, I LIKE the idea.
Re: static this sucks, we should deprecate it
Hello grauzone,
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems
stem from either wrong order or co-dependence (which needs to be
solved by the programmer.)
Your proposal needs a way to specify "no dependencies". How about
"static this : void { /+ code +/ }"?
how about "static this(){}" or "static this{}"?
Re: static this sucks, we should deprecate it
Hello davidl, Why on earth we still let the tumor grow? I would love to specify the order by myself not by the arbitrary order generated by the compiler. what would you like to replace it with?
Re: static this sucks, we should deprecate it
On Thu, 28 May 2009 08:14:45 -0400, Frank Benoit
wrote:
Unknown W. Brackets schrieb:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems stem
from either wrong order or co-dependence (which needs to be solved by
the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
In Java the
static { /* static ctor code */ }
does not have the circular dependency problem. why is that?
Probably because Java doesn't use source code as imports. It is one flaw
of D that I really wish could be fixed.
-Steve
Re: static this sucks, we should deprecate it
static this as OP said not so good. Why would you need to specify no
dependencies? The way it works now is not ambiguous and wouldn't
conflict with the dependencies syntax.
Because if you really have no dependency, you had to specify a dummy module.
As I understand, Mr. Bracket's proposal works as this:
static this {} //full dependencies (all import statements)
static this : a, b {} //only dependent from module a and b
And I'd add
static this : void {} //no dependencies at all
Re: static this sucks, we should deprecate it
grauzone wrote:
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems
stem from either wrong order or co-dependence (which needs to be
solved by the programmer.)
vote++
You can always solve those dependency issues by moving code into new,
separate modules. But the D module system requires creating a new file
for each module. You'd end up with dozens of modules, that only contain
trivial stuff for breaking circular dependencies.
Your proposal needs a way to specify "no dependencies". How about
"static this : void { /+ code +/ }"?
Specifying static this dependencies would be a nice idea, deprecating
static this as OP said not so good. Why would you need to specify no
dependencies? The way it works now is not ambiguous and wouldn't
conflict with the dependencies syntax.
Re: static this sucks, we should deprecate it
Unknown W. Brackets schrieb:
> Probably a silly idea, but what about (or similar):
>
> static this: mod.name, mod.name2, mod.name3
> {
> }
>
> For a dependency list. I may be wrong, but afaik the main problems stem
> from either wrong order or co-dependence (which needs to be solved by
> the programmer.)
>
> At least with this, you could ask the compiler for an order,
> potentially. If the other modules had no static this, it could ignore
> it, allowing future proofing.
>
> But, maybe that's an ugly hack.
>
> -[Unknown]
>
In Java the
static { /* static ctor code */ }
does not have the circular dependency problem. why is that?
Re: static this sucks, we should deprecate it
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems stem
from either wrong order or co-dependence (which needs to be solved by
the programmer.)
vote++
You can always solve those dependency issues by moving code into new,
separate modules. But the D module system requires creating a new file
for each module. You'd end up with dozens of modules, that only contain
trivial stuff for breaking circular dependencies.
Your proposal needs a way to specify "no dependencies". How about
"static this : void { /+ code +/ }"?
Re: static this sucks, we should deprecate it
Probably a silly idea, but what about (or similar):
static this: mod.name, mod.name2, mod.name3
{
}
For a dependency list. I may be wrong, but afaik the main problems stem
from either wrong order or co-dependence (which needs to be solved by
the programmer.)
At least with this, you could ask the compiler for an order,
potentially. If the other modules had no static this, it could ignore
it, allowing future proofing.
But, maybe that's an ugly hack.
-[Unknown]
davidl wrote:
Why on earth we still let the tumor grow?
I would love to specify the order by myself not by the arbitrary order
generated by the compiler.
