On Tuesday, 5 February 2013 at 21:59:53 UTC, Andrei Alexandrescu
wrote:
Just to make sure: this is about
http://forum.dlang.org/thread/[email protected].
Language design is a subjective topic. With time I have learned
it's best to not comment very much about it. I have created
dozens, maybe hundreds of tidbits of language design and
invariably I believe they had obvious merits and negligible
drawbacks. The confidence in the quality of my own language
designs has decayed exponentially over the years.
I'm telling this to put in perspective my following comment. I
think it's awesome that work like yours is discussed and
refined in this group. At the same time my opinion is that the
design is not appropriate for us. It changes semantics of
existing code
My proposal changes exactly one existing semantic, which is that
a nested struct will find symbols it doesn't find in itself in
the parent before looking at module and import levels. I'm pretty
sure it's a bad practice to shadow names in nested structs, and I
predicted no code breakage at all in the vast majority of
projects.
and fosters a cross-talk between subcomponents that has not
been time tested. It is complicated in implementation for a
benefit that's not properly motivated. At the top level it
solves the wrong problem. As stated: "The challenge is to do
better, both in terms of functionality and in terms of syntax,
than his proposal: ..." The actual challenge is to make
properties work with maximum backward compatibility, minimal
surprise, best integration with the rest of the language, and
maximum of benefits.
Andrei
I've thought about this some more. You're right in that my
proposal does not meet the first two design goals. But it doesn't
harm them either. @property can exist side-by-side with my
proposal indefinitely. The only demand you must make on
programmers is that they convert all overloads of a given local
property implementation at once so there's no repeat declaration.
As far as best integration with the rest of the language, my
proposal requires one new syntax (Highlander) and no new keyword
or even the keeping of '@property' itself. As far as maximum of
benefits, I think mine wins by far. Not only have properties been
granted the full semantic power of the
already-designed-and-implemented structs, but the features
required to make this possible have their own uses totally apart
from making properties easy.
Yes, my proposal fosters cross-talk between subcomponents that
have not been time tested, but it doesn't prevent people from
programming in the way they always have, either, with the one
exception mentioned above.
So is my proposal properly motivated?
Here's what happened. I saw a connection between what everyone is
trying to do with @properties and what the built-in struct
operators already do. I can't figure out why you would want to
have two systems when you could just design one really well
(design goal 3 above: best integration with the rest of the
language). So I figured out what needed to change to be able to
use the one system for the two purposes.
The new proposal with nested structs is confusing, but I see no
problems with it. Underneath, it's just what old-fashioned C
programming is about, a bunch of functions which accept a bunch
of variables, some of them references.
Whether or not my proposal gains any more traction than it
already has, I consider myself lucky to have discovered it. It
felt like it was just sitting right there for someone, and I was
the one to find it. I may feel a little bad that there was so
much opposition. So far, the original person who posed the
challenge has said nothing at all about it, for example, but
still, I'm glad I found it, and I don't even care at this point
if anyone else cares.
