On Thu, 14 Oct 2010 09:42:34 -0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Wed, 13 Oct 2010 20:57:54 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
Because then we are back to writeln = 42;
-Steve
:) I see that despite not valid code for what, over a year now?,
writeln = 42 still persists.
IMO, that's because the head squeaky wheel is not really fond of
properties :) It will eventually be fixed.
That said, how exactly are we back to the verb = value "problem"?
Because you can use properties in ways they weren't meant to be used.
Specifically, you can use a getter as a setter or vice versa. I admit
it's not exactly the same problem, but it's a very similar issue.
The rearrangement ambiguity was never the expressed reason for
introducing @property. In fact, despite all the passionate posts about
how wrong "verb = value" looks, it took a very specific syntax
ambiguity with delegates/opCall to warrant language inclusion. And
given the practical problems @property has been running into, it kinda
makes me wish I had run across the uniform access principle
(http://www.eiffel.com/general/column/2005/Sept_October.html) back
during the debates.
I must have said this a hundred thousand times. It has to do with the
power of the author to define usage. When you let the user define
usage, confusion ensues. To me, the delegate issue is a nice bonus, and
if that's what pushed property acceptance over the edge, so be it.
Without the restrictions, the author loses the power to define usage,
and he resorts to creating more verbose language like getFoo instead of
just foo. Welcome to Java.
-Steve
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.
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.
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.
BTW: That article on the uniform access principal has an interesting
sidebar on how Eiffel satisfied two very different sets of programmers who
desired mutually exclusive syntaxes.
(http://www.eiffel.com/general/column/2005/Sept_October.html)
