View previous topic :: View next topic |
Author |
Message |
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Thu Aug 26, 2004 11:50 am Post subject: Let's name the namespace |
|
|
It's been suggested that we should use "std" as the prefix for the modules names. I think that'd be a big mistake. It'd make compilation much more difficult and it would lead to tremendous confusion. The best way to create a strong library competing with Phobos's "std" is to brand the identity with a new prefix.
So here are some suggestions:How you like my ideas? Any other nominations? |
|
Back to top |
|
|
qbert
Joined: 30 Mar 2004 Posts: 209 Location: Dallas, Texas
|
Posted: Thu Aug 26, 2004 12:01 pm Post subject: |
|
|
Phoenix! |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Aug 26, 2004 12:03 pm Post subject: |
|
|
If I'm not mistaken, Walter has given his blessing for this project to replace Phobos, so we basically can do what we like with the namespace. Lars has made some good points about retaining the std namespace, so that the compiler dependencies don't break (GC and so on).
But the whole namespace thing is up for grabs. I'd really like to get a committee group established before this becomes chaotic. Let's not jump the gun |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Thu Aug 26, 2004 12:52 pm Post subject: What's in a name? |
|
|
I'd like to suggest Mars's alter-ego: Ares.
Also I found the quote from wikipedia's mars page rather humorus given how some feel about phobos:
Both Phobos and Deimos are tidally locked with Mars, always pointing the same face towards it. Since Phobos orbits around Mars faster than the planet itself rotates, tidal forces are slowly but steadily decreasing its orbital radius. At some point in the future Phobos will be broken up by gravitational forces (see Roche limit). Deimos, on the other hand, is far enough away that its orbit is being slowly boosted instead.
As for mention of a committee... I think that we should be prepared to scale the amount of communication to coordinate with the number of people involved. Proceeding as an anarchy, as we are now, will work well until we get past a dozen or so people.
Should it become apparent that we need more process control, then I'd reccomend we do something along the lines of Boost's commitee processes. At the very least, something open, free (as in speech and beer) and democratic.
At the very least, a good, impartial voting booth would be useful *now*. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Aug 26, 2004 1:01 pm Post subject: |
|
|
Too funny, Eric
All good points. I'd like to suggest that one of the first tasks of a "steering group" should be to figure out which model to adopt ... |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Aug 26, 2004 1:29 pm Post subject: |
|
|
sean wrote: | One option would be how Boost does things, as I outlined here. The only consideration for this project is that some initial groundwork probably has to be laid--interface conventions and the like. Maybe that type of thing could be handled by an informal vote? I'm still not convinced a "steering group" is entirely necessary, though it may prove to be if things become disorganized. |
I'd tend to agree, Sean. I suppose my concern is that without a rudder (at least initially) it'll quickly become like the NG currently is. Perhaps that's not a valid concern at all. Of course, the "steering group" might decide to disband within a week, and turn over the reins to whatever they think best
Further thoughts? |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Aug 26, 2004 1:41 pm Post subject: |
|
|
(I moved my post to the other thread as it seemed more appropriate)
I think if the group remains fairly small at the outset then entropy shouldn't be much of a problem, but who knows? I certainly wouldn't object too strongly to a steering group as they're all people we have some degree of faith in anyway. |
|
Back to top |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Thu Aug 26, 2004 1:51 pm Post subject: |
|
|
kris wrote: | If I'm not mistaken, Walter has given his blessing for this project to replace Phobos, so we basically can do what we like with the namespace. | Yes, it may eventually replace Phobos. But I'd like for it to be easy to use from day one. I want this new library to be friendly during the transition period. And I don't want to have to ask "Which std is that?" I want to know that std is the current official Phobos and phoenix is the new Phobos.
kris wrote: | Lars has made some good points about retaining the std namespace, so that the compiler dependencies don't break (GC and so on). |
kris wrote: | But the whole namespace thing is up for grabs. I'd really like to get a committee group established before this becomes chaotic. Let's not jump the gun | I'm not trying to jump the gun, but I think this is an important issue, too.
I don't know how we can decide the who without deciding the what. Okay, now I'll go talk about membership in the other topic... |
|
Back to top |
|
|
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sat Aug 28, 2004 5:33 am Post subject: |
|
|
I quite firmly believe that we should use std. (although I get the impression that 'we' decided elsewise?) I understand that this will clash with Phobos, but I was under some other impression that we want a replacement, thus Phoenix IS Phobos and in the end there shouldn't be any room for conflict. There is no point in standardizing a library (if that is what we are going to do) if there are conflicting versions of them. Those who don't want to be involved in the production of phoenix should use Phobos until Phoenix is ready, at which point it should be included in DMD, or at least a library that use the same API. |
|
Back to top |
|
|
andy
Joined: 15 Mar 2004 Posts: 71
|
Posted: Sat Aug 28, 2004 10:14 am Post subject: |
|
|
larsivi wrote: | I quite firmly believe that we should use std. | Yes, please.
There isn't going to be much code using Phoenix until it's been stabilized anyway, so conflict issues shouldn't be a problem.
Besides, DMD hasn't hit 1.0 yet, so we should take advantage of the opportunity to write a clearer, better library without having to dance on eggs for the sake of compatibility. _________________ "Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Sat Aug 28, 2004 11:44 am Post subject: |
|
|
larsivi wrote: | I quite firmly believe that we should use std. (although I get the impression that 'we' decided elsewise?) |
Well, 'we' really is anyone who cares to jump in, as you have. Thanks for your input.
The general feeling up until this point, is that 'phoenix' would be acceptable, at least in the short term.
I'll go out on a limb and say that most likely, usage of 'phoenix' in library imports can be replaced with 'std' when it becomes mature enough to replace phobos outright. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
teqdruid
Joined: 11 May 2004 Posts: 390 Location: UMD
|
Posted: Sat Aug 28, 2004 12:10 pm Post subject: std |
|
|
The only reason (I see) to use anything but std is if we plan on limping along for awhile and rely on phobos, which I think is a BAD idea. If pheonix isn't going to depend on phobos, then we will need to have several std modules (such as std.object) that are going to conflict anyway, so why not put everything in std? |
|
Back to top |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Sat Aug 28, 2004 12:40 pm Post subject: Re: std |
|
|
demmegod wrote: | The only reason (I see) to use anything but std is if we plan on limping along for awhile and rely on phobos, which I think is a BAD idea. | Doesn't the compiler have a bunch of secret dependencies on phobos (I think it's more than just object.d)? We'll need to figure out those before we can just delete the phobos directory.
I'm also thinking the best way we can "sell" this new library is to make it easy for others to try. Making installation easy would be good. Making it impossible to re-built stuff that they have that still depends on Phobos would be bad.
An abundance of examples would be good. We could compare how a program using phobos would look and then demonstrate how the new way would work. If we use a separate namespace, they can compile both easily (seeing is believing) without mucking around in the dmd\src and dmd\lib directories.
By the way, there is no "std.object" (that'd make too much sense). The root of the phobos directory has "object.d", "crc32.d", "errno.c", "gcstats.d", etc. I think it'd be terrific if those were moved into the "std" or "internal" directory. |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Sat Aug 28, 2004 12:52 pm Post subject: Re: std |
|
|
jcc7 wrote: | Doesn't the compiler have a bunch of secret dependencies on phobos (I think it's more than just object.d)? We'll need to figure out those before we can just delete the phobos directory.
...
By the way, there is no "std.object" (that'd make too much sense). The root of the phobos directory has "object.d", "crc32.d", "errno.c", "gcstats.d", etc. I think it'd be terrific if those were moved into the "std" or "internal" directory. |
I think you may have just answered your own question. If I had to hazard a guess, the things DMD depends on are in /phobos and /phobos/internal. But all that probably means are that we can't go changing interfaces and such. It would probably still be safe to move object into std if we wanted to. |
|
Back to top |
|
|
andy
Joined: 15 Mar 2004 Posts: 71
|
Posted: Sat Aug 28, 2004 1:52 pm Post subject: Re: std |
|
|
jcc7 wrote: | I'm also thinking the best way we can "sell" this new library is to make it easy for others to try. Making installation easy would be good. Making it impossible to re-built stuff that they have that still depends on Phobos would be bad. | I think it would be worthwhile to use Phobos as a base and make gradual (but not necessarily compatible) changes to it. There's a lot of stuff in Phobos that's worth keeping around, and, for all its problems, it has had a pretty good stress test.
I hadn't considered mixing Phoenix with precompiled libraries that depend on Phobos, though. This would be a sticking point.
I don't think it changes anything, though. There is going to be a transition period no matter what we do, so we may as well make it a quick one while we have the chance to make a clean break.
What we should be worrying about instead is breaking existing code that uses Phoenix, not Phobos.
Quote: | By the way, there is no "std.object" (that'd make too much sense). The root of the phobos directory has "object.d", "crc32.d", "errno.c", "gcstats.d", etc. I think it'd be terrific if those were moved into the "std" or "internal" directory. | These can't be moved without changes to the compiler. _________________ "Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear |
|
Back to top |
|
|
|