Bill Baxter wrote:
On Tue, Jul 28, 2009 at 6:54 AM, Andrei
Alexandrescu<seewebsiteforem...@erdani.org> wrote:
Well there are quite a few other things that are arguably against C look and
feel, such as the scope statement. I've never had a problem understanding
code because of lacking "()", and I never ever write them.
That may be true, but you are also not an average user by any means.
So surveying yourself may not give so accurate a reflection of
opinions at large.
Like Joel Spoelsky and others say about GUIs -- never take your own
opinion that a GUI you have written is "intuitive". You need to do at
a minimum a couple of random "hallway checks" -- that is, getting
random people passing by in the hallway to try it out without
explaining it to them. So far I think we have two people -- you and
Walter -- who think that the current system is good.
I think you're right that people *can* get used to losing the visual
distinction between functions and fields. But I find the distinction
to be a useful and unobtrusive indication of the programmer's intent.
So I don't see losing the distinction to be worth saving a few
keystrokes. If there were a distinction then we could be pretty sure
that .empty was a property and .empty() was an action. Sure I can
get used to having to learn which is which on a per-library basis, but
I don't see why I should consider having to keep more stuff in my head
to be a net win. In fact I'm kind of envious of those languages where
? and ! can by used in identifiers to indicate predicates and
mutators.
For the same reason I started to dislike like the direction some of
these syntax proposals were taking. Too much for me to keep in my
head. But the "property { ... }" syntax is very easy to remember and
doesn't look ugly.
Look, if we add a generic attributes syntax (like @attr) we could
perhaps use it for many of the following:
abstract
deprecated
align
case
debug
default
export
extern
final
lazy
override
package
private
protected
public
scope
shared
unittest
volitile
Storage classes are, in particular, kinds of attributes of a type.
Now we may not want to go so hog wild putting @this and @that
everywhere, but if we did we could get rid of 19 keywords right there,
and add @property also without adding a new keyword.
Definitely. I think attributes/annotations is the best solution for
this. It's also the most extensible way to do it. The lexer and parser
doesn't need to change for each new attribute. Maybe just the semantic pass.
