Hi,

I just noticed that std.concurrency public imports more or less all of the synchronization modules from druntime. This caused a whole bunch of name conflicts in my code. Is this really needed? The average code written with std.concurrency is not going to need *any* of these primitives - I mean, that's the entire idea. In my case, I'm doing very low-level hackery/abuse inside a garbage collector implementation, so that doesn't really count as normal usage.

I know it would be a breaking change, but could we please get rid of those public imports? I honestly doubt anyone's relying on these, and they're frankly a pain in the ass.

(Also, the core.thread import is private, but these are public - wat?)

Regards,
Alex
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:

> Hi,
> 
> I just noticed that std.concurrency public imports more or less all of the synchronization modules from druntime. This caused a whole bunch of name conflicts in my code. Is this really needed? The average code written with std.concurrency is not going to need *any* of these primitives - I mean, that's the entire idea. In my case, I'm doing very low-level hackery/abuse inside a garbage collector implementation, so that doesn't really count as normal usage.
> 
> I know it would be a breaking change, but could we please get rid of those public imports? I honestly doubt anyone's relying on these, and they're frankly a pain in the ass.
> 
> (Also, the core.thread import is private, but these are public - wat?)


I think it's like this because TDPL stated it works this way.  I'd have to re-read the chapter to be sure though.
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

I just looked over the concurrency chapter and couldn't find any mention of this.

Regards,
Alex

On Thu, Apr 26, 2012 at 8:51 PM, Sean Kelly <sean@invisibleduck.org> wrote:

> On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:
>
> > Hi,
> >
> > I just noticed that std.concurrency public imports more or less all of the synchronization modules from druntime. This caused a whole bunch of name conflicts in my code. Is this really needed? The average code written with std.concurrency is not going to need *any* of these primitives - I mean, that's the entire idea. In my case, I'm doing very low-level hackery/abuse inside a garbage collector implementation, so that doesn't really count as normal usage.
> >
> > I know it would be a breaking change, but could we please get rid of those public imports? I honestly doubt anyone's relying on these, and they're frankly a pain in the ass.
> >
> > (Also, the core.thread import is private, but these are public - wat?)
>
>
> I think it's like this because TDPL stated it works this way.  I'd have to
> re-read the chapter to be sure though.
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

I think it was the suggestion that std.concurrency was to be the only import necessary for all things related to concurrency.  core.thread was left out because spawn() was supposed to be used instead.  I'd be fine with making the imports private though.

On Apr 26, 2012, at 1:21 PM, Alex Rønne Petersen wrote:

> I just looked over the concurrency chapter and couldn't find any mention of this.
> 
> Regards,
> Alex
> 
> On Thu, Apr 26, 2012 at 8:51 PM, Sean Kelly <sean@invisibleduck.org> wrote: On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:
> 
> > Hi,
> >
> > I just noticed that std.concurrency public imports more or less all of the synchronization modules from druntime. This caused a whole bunch of name conflicts in my code. Is this really needed? The average code written with std.concurrency is not going to need *any* of these primitives - I mean, that's the entire idea. In my case, I'm doing very low-level hackery/abuse inside a garbage collector implementation, so that doesn't really count as normal usage.
> >
> > I know it would be a breaking change, but could we please get rid of those public imports? I honestly doubt anyone's relying on these, and they're frankly a pain in the ass.
> >
> > (Also, the core.thread import is private, but these are public - wat?)
> 
> 
> I think it's like this because TDPL stated it works this way.  I'd have to re-read the chapter to be sure though.
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

My argument against this is just that these synchronization primitives more or less go completely against the paradigm that std.concurrency encourages. It just seems very awkward.

Andrei, do you have any input on this?

Regards,
Alex

On Tue, May 1, 2012 at 6:42 PM, Sean Kelly <sean@invisibleduck.org> wrote:

> I think it was the suggestion that std.concurrency was to be the only import necessary for all things related to concurrency.  core.thread was left out because spawn() was supposed to be used instead.  I'd be fine with making the imports private though.
>
> On Apr 26, 2012, at 1:21 PM, Alex Rønne Petersen wrote:
>
> > I just looked over the concurrency chapter and couldn't find any mention
> of this.
> >
> > Regards,
> > Alex
> >
> > On Thu, Apr 26, 2012 at 8:51 PM, Sean Kelly <sean@invisibleduck.org>
> wrote:
> > On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:
> >
> > > Hi,
> > >
> > > I just noticed that std.concurrency public imports more or less all of the synchronization modules from druntime. This caused a whole bunch of name conflicts in my code. Is this really needed? The average code written with std.concurrency is not going to need *any* of these primitives - I mean, that's the entire idea. In my case, I'm doing very low-level hackery/abuse inside a garbage collector implementation, so that doesn't really count as normal usage.
> > >
> > > I know it would be a breaking change, but could we please get rid of those public imports? I honestly doubt anyone's relying on these, and they're frankly a pain in the ass.
> > >
> > > (Also, the core.thread import is private, but these are public - wat?)
> >
> >
> > I think it's like this because TDPL stated it works this way.  I'd have
> to re-read the chapter to be sure though.
> > _______________________________________________
> > phobos mailing list
> > phobos@puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> >
> > _______________________________________________
> > phobos mailing list
> > phobos@puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
>
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

TDPL doesn't prescribe one way or the other. What are some primitives in core that are reasonably useful to client high-level code?

Andrei

On 5/1/12 1:20 PM, Alex Rønne Petersen wrote:
> My argument against this is just that these synchronization primitives
> more or less go completely against the paradigm that std.concurrency
> encourages. It just seems very awkward.
>
> Andrei, do you have any input on this?
>
> Regards,
> Alex
>
> On Tue, May 1, 2012 at 6:42 PM, Sean Kelly <sean@invisibleduck.org
> <mailto:sean@invisibleduck.org>> wrote:
>
>     I think it was the suggestion that std.concurrency was to be the
>     only import necessary for all things related to concurrency.
>       core.thread was left out because spawn() was supposed to be used
>     instead.  I'd be fine with making the imports private though.
>
>     On Apr 26, 2012, at 1:21 PM, Alex Rønne Petersen wrote:
>
>      > I just looked over the concurrency chapter and couldn't find any
>     mention of this.
>      >
>      > Regards,
>      > Alex
>      >
>      > On Thu, Apr 26, 2012 at 8:51 PM, Sean Kelly
>     <sean@invisibleduck.org <mailto:sean@invisibleduck.org>> wrote:
>      > On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:
>      >
>      > > Hi,
>      > >
>      > > I just noticed that std.concurrency public imports more or less
>     all of
>      > > the synchronization modules from druntime. This caused a whole
>     bunch
>      > > of name conflicts in my code. Is this really needed? The
>     average code
>      > > written with std.concurrency is not going to need *any* of these
>      > > primitives - I mean, that's the entire idea. In my case, I'm doing
>      > > very low-level hackery/abuse inside a garbage collector
>      > > implementation, so that doesn't really count as normal usage.
>      > >
>      > > I know it would be a breaking change, but could we please get
>     rid of
>      > > those public imports? I honestly doubt anyone's relying on
>     these, and
>      > > they're frankly a pain in the ass.
>      > >
>      > > (Also, the core.thread import is private, but these are public
>     - wat?)
>      >
>      >
>      > I think it's like this because TDPL stated it works this way.
>       I'd have to re-read the chapter to be sure though.
>      > _______________________________________________
>      > phobos mailing list
>      > phobos@puremagic.com <mailto:phobos@puremagic.com>
>      > http://lists.puremagic.com/mailman/listinfo/phobos
>      >
>      > _______________________________________________
>      > phobos mailing list
>      > phobos@puremagic.com <mailto:phobos@puremagic.com>
>      > http://lists.puremagic.com/mailman/listinfo/phobos
>
>     _______________________________________________
>     phobos mailing list
>     phobos@puremagic.com <mailto:phobos@puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
>
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

I honestly don't think any of them are. They all have the potential to cause seriously *nasty* deadlocks.

I could maybe see myself using core.sync.barrier in some very specific cases, but that's only because I've dealt with message-passing systems a lot and know how to avoid the most common pitfalls when doing synchronization in them. IMHO we should be directing people away from synchronization primitives when doing message-passing and maybe even make it clearer in the documentation that using them in message-passing systems is a recipe for disaster, may eat your laundry, etc.

Besides, I don't think any of the synchronization primitives are shared/immutable-friendly (and probably can't be easily).

Regards,
Alex

On Tue, May 1, 2012 at 7:26 PM, Andrei Alexandrescu <andrei@erdani.com>wrote:

> TDPL doesn't prescribe one way or the other. What are some primitives in core that are reasonably useful to client high-level code?
>
> Andrei
>
>
> On 5/1/12 1:20 PM, Alex Rønne Petersen wrote:
>
>> My argument against this is just that these synchronization primitives more or less go completely against the paradigm that std.concurrency encourages. It just seems very awkward.
>>
>> Andrei, do you have any input on this?
>>
>> Regards,
>> Alex
>>
>> On Tue, May 1, 2012 at 6:42 PM, Sean Kelly <sean@invisibleduck.org <mailto:sean@invisibleduck.org**>> wrote:
>>
>>    I think it was the suggestion that std.concurrency was to be the
>>    only import necessary for all things related to concurrency.
>>      core.thread was left out because spawn() was supposed to be used
>>    instead.  I'd be fine with making the imports private though.
>>
>>    On Apr 26, 2012, at 1:21 PM, Alex Rønne Petersen wrote:
>>
>>     > I just looked over the concurrency chapter and couldn't find any
>>    mention of this.
>>     >
>>     > Regards,
>>     > Alex
>>     >
>>     > On Thu, Apr 26, 2012 at 8:51 PM, Sean Kelly
>>    <sean@invisibleduck.org <mailto:sean@invisibleduck.org**>> wrote:
>>     > On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:
>>     >
>>     > > Hi,
>>     > >
>>     > > I just noticed that std.concurrency public imports more or less
>>    all of
>>     > > the synchronization modules from druntime. This caused a whole
>>    bunch
>>     > > of name conflicts in my code. Is this really needed? The
>>    average code
>>     > > written with std.concurrency is not going to need *any* of these
>>     > > primitives - I mean, that's the entire idea. In my case, I'm doing
>>     > > very low-level hackery/abuse inside a garbage collector
>>     > > implementation, so that doesn't really count as normal usage.
>>     > >
>>     > > I know it would be a breaking change, but could we please get
>>    rid of
>>     > > those public imports? I honestly doubt anyone's relying on
>>    these, and
>>     > > they're frankly a pain in the ass.
>>     > >
>>     > > (Also, the core.thread import is private, but these are public
>>    - wat?)
>>     >
>>     >
>>     > I think it's like this because TDPL stated it works this way.
>>      I'd have to re-read the chapter to be sure though.
>>     > ______________________________**_________________
>>     > phobos mailing list
>>     > phobos@puremagic.com <mailto:phobos@puremagic.com>
>>
>>     > http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos>
>>     >
>>     > ______________________________**_________________
>>     > phobos mailing list
>>     > phobos@puremagic.com <mailto:phobos@puremagic.com>
>>
>>     > http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos>
>>
>>    ______________________________**_________________
>>    phobos mailing list
>>    phobos@puremagic.com <mailto:phobos@puremagic.com>
>>
>>    http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos>
>>
>>
>>
>>
>> ______________________________**_________________
>> phobos mailing list
>> phobos@puremagic.com
>> http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos>
>>
>

Then we probably should deprecate the import.

Andrei

On 5/1/12 1:58 PM, Alex Rønne Petersen wrote:
> I honestly don't think any of them are. They all have the potential to
> cause seriously *nasty* deadlocks.
>
> I could maybe see myself using core.sync.barrier in some very specific
> cases, but that's only because I've dealt with message-passing systems a
> lot and know how to avoid the most common pitfalls when doing
> synchronization in them. IMHO we should be directing people away from
> synchronization primitives when doing message-passing and maybe even
> make it clearer in the documentation that using them in message-passing
> systems is a recipe for disaster, may eat your laundry, etc.
>
> Besides, I don't think any of the synchronization primitives are
> shared/immutable-friendly (and probably can't be easily).
>
> Regards,
> Alex
>
> On Tue, May 1, 2012 at 7:26 PM, Andrei Alexandrescu <andrei@erdani.com
> <mailto:andrei@erdani.com>> wrote:
>
>     TDPL doesn't prescribe one way or the other. What are some
>     primitives in core that are reasonably useful to client high-level code?
>
>     Andrei
>
>
>     On 5/1/12 1:20 PM, Alex Rønne Petersen wrote:
>
>         My argument against this is just that these synchronization
>         primitives
>         more or less go completely against the paradigm that std.concurrency
>         encourages. It just seems very awkward.
>
>         Andrei, do you have any input on this?
>
>         Regards,
>         Alex
>
>         On Tue, May 1, 2012 at 6:42 PM, Sean Kelly
>         <sean@invisibleduck.org <mailto:sean@invisibleduck.org>
>         <mailto:sean@invisibleduck.org
>         <mailto:sean@invisibleduck.org>__>> wrote:
>
>             I think it was the suggestion that std.concurrency was to be the
>             only import necessary for all things related to concurrency.
>               core.thread was left out because spawn() was supposed to
>         be used
>             instead.  I'd be fine with making the imports private though.
>
>             On Apr 26, 2012, at 1:21 PM, Alex Rønne Petersen wrote:
>
>          > I just looked over the concurrency chapter and couldn't find any
>             mention of this.
>          >
>          > Regards,
>          > Alex
>          >
>          > On Thu, Apr 26, 2012 at 8:51 PM, Sean Kelly
>         <sean@invisibleduck.org <mailto:sean@invisibleduck.org>
>         <mailto:sean@invisibleduck.org
>         <mailto:sean@invisibleduck.org>__>> wrote:
>          > On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:
>          >
>          > > Hi,
>          > >
>          > > I just noticed that std.concurrency public imports more or less
>             all of
>          > > the synchronization modules from druntime. This caused a whole
>             bunch
>          > > of name conflicts in my code. Is this really needed? The
>             average code
>          > > written with std.concurrency is not going to need *any* of
>         these
>          > > primitives - I mean, that's the entire idea. In my case,
>         I'm doing
>          > > very low-level hackery/abuse inside a garbage collector
>          > > implementation, so that doesn't really count as normal usage.
>          > >
>          > > I know it would be a breaking change, but could we please get
>             rid of
>          > > those public imports? I honestly doubt anyone's relying on
>             these, and
>          > > they're frankly a pain in the ass.
>          > >
>          > > (Also, the core.thread import is private, but these are public
>             - wat?)
>          >
>          >
>          > I think it's like this because TDPL stated it works this way.
>               I'd have to re-read the chapter to be sure though.
>          > _________________________________________________
>          > phobos mailing list
>          > phobos@puremagic.com <mailto:phobos@puremagic.com>
>         <mailto:phobos@puremagic.com <mailto:phobos@puremagic.com>>
>
>          > http://lists.puremagic.com/__mailman/listinfo/phobos
>         <http://lists.puremagic.com/mailman/listinfo/phobos>
>          >
>          > _________________________________________________
>          > phobos mailing list
>          > phobos@puremagic.com <mailto:phobos@puremagic.com>
>         <mailto:phobos@puremagic.com <mailto:phobos@puremagic.com>>
>
>          > http://lists.puremagic.com/__mailman/listinfo/phobos
>         <http://lists.puremagic.com/mailman/listinfo/phobos>
>
>             _________________________________________________
>             phobos mailing list
>         phobos@puremagic.com <mailto:phobos@puremagic.com>
>         <mailto:phobos@puremagic.com <mailto:phobos@puremagic.com>>
>
>         http://lists.puremagic.com/__mailman/listinfo/phobos
>         <http://lists.puremagic.com/mailman/listinfo/phobos>
>
>
>
>
>         _________________________________________________
>         phobos mailing list
>         phobos@puremagic.com <mailto:phobos@puremagic.com>
>         http://lists.puremagic.com/__mailman/listinfo/phobos
>         <http://lists.puremagic.com/mailman/listinfo/phobos>
>
>
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

How are we going to do this? It's not obvious in the documentation that std.concurrency imports these core modules at all anyway. Do we want a proper deprecation process or just private-ify the imports here and now?

Regards,
Alex

On Tue, May 1, 2012 at 8:21 PM, Andrei Alexandrescu <andrei@erdani.com>wrote:

> Then we probably should deprecate the import.
>
> Andrei
>
>
> On 5/1/12 1:58 PM, Alex Rønne Petersen wrote:
>
>> I honestly don't think any of them are. They all have the potential to cause seriously *nasty* deadlocks.
>>
>> I could maybe see myself using core.sync.barrier in some very specific cases, but that's only because I've dealt with message-passing systems a lot and know how to avoid the most common pitfalls when doing synchronization in them. IMHO we should be directing people away from synchronization primitives when doing message-passing and maybe even make it clearer in the documentation that using them in message-passing systems is a recipe for disaster, may eat your laundry, etc.
>>
>> Besides, I don't think any of the synchronization primitives are shared/immutable-friendly (and probably can't be easily).
>>
>> Regards,
>> Alex
>>
>> On Tue, May 1, 2012 at 7:26 PM, Andrei Alexandrescu <andrei@erdani.com <mailto:andrei@erdani.com>> wrote:
>>
>>    TDPL doesn't prescribe one way or the other. What are some
>>    primitives in core that are reasonably useful to client high-level
>> code?
>>
>>    Andrei
>>
>>
>>    On 5/1/12 1:20 PM, Alex Rønne Petersen wrote:
>>
>>        My argument against this is just that these synchronization
>>        primitives
>>        more or less go completely against the paradigm that
>> std.concurrency
>>        encourages. It just seems very awkward.
>>
>>        Andrei, do you have any input on this?
>>
>>        Regards,
>>        Alex
>>
>>        On Tue, May 1, 2012 at 6:42 PM, Sean Kelly
>>        <sean@invisibleduck.org <mailto:sean@invisibleduck.org**>
>>        <mailto:sean@invisibleduck.org
>>
>>        <mailto:sean@invisibleduck.org**>__>> wrote:
>>
>>            I think it was the suggestion that std.concurrency was to be
>> the
>>            only import necessary for all things related to concurrency.
>>              core.thread was left out because spawn() was supposed to
>>        be used
>>            instead.  I'd be fine with making the imports private though.
>>
>>            On Apr 26, 2012, at 1:21 PM, Alex Rønne Petersen wrote:
>>
>>         > I just looked over the concurrency chapter and couldn't find any
>>            mention of this.
>>         >
>>         > Regards,
>>         > Alex
>>         >
>>         > On Thu, Apr 26, 2012 at 8:51 PM, Sean Kelly
>>        <sean@invisibleduck.org <mailto:sean@invisibleduck.org**>
>>        <mailto:sean@invisibleduck.org
>>
>>        <mailto:sean@invisibleduck.org**>__>> wrote:
>>         > On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:
>>         >
>>         > > Hi,
>>         > >
>>         > > I just noticed that std.concurrency public imports more or
>> less
>>            all of
>>         > > the synchronization modules from druntime. This caused a whole
>>            bunch
>>         > > of name conflicts in my code. Is this really needed? The
>>            average code
>>         > > written with std.concurrency is not going to need *any* of
>>        these
>>         > > primitives - I mean, that's the entire idea. In my case,
>>        I'm doing
>>         > > very low-level hackery/abuse inside a garbage collector
>>         > > implementation, so that doesn't really count as normal usage.
>>         > >
>>         > > I know it would be a breaking change, but could we please get
>>            rid of
>>         > > those public imports? I honestly doubt anyone's relying on
>>            these, and
>>         > > they're frankly a pain in the ass.
>>         > >
>>         > > (Also, the core.thread import is private, but these are public
>>            - wat?)
>>         >
>>         >
>>         > I think it's like this because TDPL stated it works this way.
>>              I'd have to re-read the chapter to be sure though.
>>         > ______________________________**___________________
>>
>>         > phobos mailing list
>>         > phobos@puremagic.com <mailto:phobos@puremagic.com>
>>        <mailto:phobos@puremagic.com <mailto:phobos@puremagic.com>>
>>
>>         > http://lists.puremagic.com/__**mailman/listinfo/phobos<http://lists.puremagic.com/__mailman/listinfo/phobos>
>>        <http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos>
>> >
>>         >
>>         > ______________________________**___________________
>>
>>         > phobos mailing list
>>         > phobos@puremagic.com <mailto:phobos@puremagic.com>
>>        <mailto:phobos@puremagic.com <mailto:phobos@puremagic.com>>
>>
>>         > http://lists.puremagic.com/__**mailman/listinfo/phobos<http://lists.puremagic.com/__mailman/listinfo/phobos>
>>        <http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos>
>> >
>>
>>            ______________________________**___________________
>>
>>            phobos mailing list
>>        phobos@puremagic.com <mailto:phobos@puremagic.com>
>>        <mailto:phobos@puremagic.com <mailto:phobos@puremagic.com>>
>>
>>        http://lists.puremagic.com/__**mailman/listinfo/phobos<http://lists.puremagic.com/__mailman/listinfo/phobos>
>>        <http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos>
>> >
>>
>>
>>
>>
>>        ______________________________**___________________
>>
>>        phobos mailing list
>>        phobos@puremagic.com <mailto:phobos@puremagic.com>
>>        http://lists.puremagic.com/__**mailman/listinfo/phobos<http://lists.puremagic.com/__mailman/listinfo/phobos>
>>        <http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos>
>> >
>>
>>
>>

On Tuesday, May 01, 2012 22:54:43 Alex Rønne Petersen wrote:
> How are we going to do this? It's not obvious in the documentation that std.concurrency imports these core modules at all anyway. Do we want a proper deprecation process or just private-ify the imports here and now?

There isn't really a way to have a proper deprecation process with imports. The best that you can do is give a notice somewhere that they're going to be made private in the future and then later make them private. deprecate can't get involved at all AFAIK.

Personally, I'd argue that as long as the fact that the imports are public isn't mentioned in the documentation, we might as well just make them private immediately.

- Jonathan M Davis
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos