On 3/19/2011 10:54 AM, Andrei Alexandrescu wrote:
On 03/18/2011 11:40 PM, dsimcha wrote:
It should just be private. The fact that it's public is an artifact of
when I was designing worker-local storage and didn't know how it was
going to work yet. I never thought to revisit this until now. It really
isn't useful to client code.
It could be public and undocumented.
I've already made it private. I can't see what purpose having it public
would serve. The fact that it was public before was **purely** an
oversight.
* defaultPoolThreads - should it be a @property?
Yes. In spirit it's a global variable. It requires some extra
machinations, though, to be threadsafe, which is why it's not
implemented as a simple global variable.
Then it should be a @property. I think ddoc doesn't reflect that, but an
example could.
Right. It's always been @property but ddoc doesn't reflect this. I've
changed the docs slightly to call it a "property" instead of a
"function". It seems like overkill to me to give examples for this,
though, since it's just a getter and a setter.
* No example for task().
???? Yes there is, for both flavors, though these could admittedly be
improved. Only the safe version doesn't have an example, and this is
just a more restricted version of the function pointer case, so it seems
silly to make a separate example for it.
Towards the bottom of the document there are overloads of task that
don't have examples.
You mean TaskPool.task()? Since these are such slight variations of the
other overloads, I thought an example would be overkill. Since people
less familiar with the library don't think so, though, I've added
examples that are accordingly slight variations of the examples for the
other overloads.
* What is 'run' in the definition of safe task()?
It's just the run() adapter function. Isn't that obvious?
I'm referring to this:
Task!(run,TypeTuple!(F,Args)) task(F, Args...)(scope F delegateOrFp,
Args args);
What is "run"?
Ok, I ended up moving the docs for run() directly above the stuff that
uses it. run() is described as "Calls a delegate or function pointer
with args. This is an adapter that makes Task work with delegates,
function pointers and functors instead of just aliases. It is included
in the documentation to clarify how this case is handled, but is not
meant to be used directly by client code."
I know the Higher Principles of Encapsulation say this should be private
and the relevant overloads should return auto. I strongly believe,
though, that being anal about encapsulation of this detail is silly
since it is so unlikely to change and that exposing it helps to clarify
what's really going on here. Encapsulation is good up to a point, but
sometimes it's just easier to think about things when you know how they
really work at a concrete level, and this tradeoff needs to be weighted.
