On Thu, 14 Oct 2010 20:28:45 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
First, to avoid confusion, I'd like to separate inappropriate usage at
the binary level from textual/syntax level. For example, casting,
compile-time reflection and .tupleof are all ways to circumvent the
fundamental restrictions of a library in order to achieve inappropriate
binary access, while alias and 'with()' allow (harmless?) syntactical
changes, changing a library's effective API. The decision between what
is and isn't inappropriate syntax is generally made by either the
language designer or by your project's style guide. Indeed, libraries
that define extensive changes in a language's appropriate syntax are
often referred to as being domain specific languages instead of a simple
libraries, modules or packages. And part of the reason for this
nomenclature change is that DSLs, unlike libraries, tend to compose
poorly and require varying levels of programmer buy-in. This is one
reason why none of the DSL/macro features implemented and/or proposed
for D are pervasive; they all have a very specific and defined radius of
comprehension and scope.
as well you can rename anything you want. Hell, for most D projects you
have the source, just rename it!
But if you want your code to be readable, you should follow the convention
that the author intended, because that's how everyone else will read it
and understand it.
Which brings us to the concept of methods behaving syntactically as
fields. The three solutions put forth so far are: methods-as-properties,
which allow methods to behave like methods or fields; @property, which
force specific methods to behave only as fields; and the uniform access
principle, which allows methods _and_ fields to behave like either
methods or fields. Both MAP and UAP are language level syntax changes,
while @property gives libraries pervasive DSL-lite abilities. The main
advantages of MAP and UAP is that they allow the project team to better
select a coding style that suites them. On the downside, neither MAP nor
UAP are mainstream concepts, so it can take people time to adapt, and
more coding style choice inevitably breeds more coding style wars (i.e.
names_with_underscores vs CamelCase, csHangarian vbNotation, sVNs vs
longVariableNames, etc.). @property, on the other hand, moves the coding
style choice to the library author, which, on the plus side, is similar
to how C# handles things. However, it forces the author to choose a
single coding style, which may not be appropriate for all users for all
time. (read: poor user buy-in) Worse, an author's style choice will
enviably conflict with either the project's style guidelines or a second
author's library, leading to user code which has to constantly change
styles. (read: poor composition) And the composition problem only
worsens for generic code.
Couldn't disagree more. An API without appropriate function names ==
fail. And the call style is part of the function name, like it or not.
People see x = y, they think field. People see x(y) they think function.
No matter the camel casing, or spacing between parentheses, or prefixes to
the function name, or whether the curly brace is on the next line or not.
It amazes me how many times we have to go over this.
I fully agree that the ability to define the acceptable syntactic usage
is critical to avoiding confusion, I simply believe that putting that
responsibility in that hands of a project's style guide provides the
best consistency and is the most inclusive. Furthermore, I would point
out that ultimately the author serves the user; they are his/her
customer and good libraries don't unnecessarily restrict their users.
Indeed, one of D's best feature is the collection of things, both great
and small, that lets it get out of the way of the coding process.
I want the *compiler* to tell me when I incorrectly used a property, not a
style guide (which requires a person for interpretation).
-Steve
