On Mon, 28 Feb 2011 19:50:44 -0500, Stewart Gordon <[email protected]>
wrote:
On 28/02/2011 07:03, Bekenn wrote:
HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null,
hDestWindowOverride: null, pDirtyRegion: null);
One advantage is that it would encourage self-documenting code, partly
because the meaning is clearer at the caller side, and partly because
library programmers would be encouraged more to make parameter names
meaningful.
It also means that you don't have to remember which order the parameters
of a function go in. Though this is only useful if you can remember
what the parameters are called. For example, string search functions
vary - needle/haystack, str/substr, search/seek, for/in. (OK, so some
of these I've thought up on the spot, and for/in wouldn't work (nice as
it may be) as they're keywords, but you get the idea.)
Trouble is it would create fragility, as parameter names would become a
new thing that can't be changed once decided without breaking existing
code. So it would be important to get them right from the beginning,
and there'll be a time when the feature has just been introduced during
which library programmers are in the process of changing parameter names
to something meaningful. But one way around that would be to support
parameter aliases, which would also confer a few more benefits.
This is probably the worse concern, because right now, phobos has been
created without the intention that parameter names will be used at the
call site. Despite all the concern, I believe phobos has been naming
parameters just fine. If there are any poorly named parameters, they
either a) aren't worth worrying about or b) should be renamed anyways
(even if named parameter calling is not introduced).
I think the alias idea is too much...
-Steve
