Properties

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Daniel Keep (daniel.keep.lists at gmail.com)'s article
>> Why change the language when you can just abuse it's already-existing
>> features? :D
>>    -- Daniel "downs is my hero"
> 
> This is precisely the attitude that left C++ with all of the cruft and baggage it
> has.  Yes, if something can be implemented *elegantly, efficiently, and with clean
> syntax* in a library, then it doesn't belong in the core language.  Yes, powerful
> language features like templates, mixins, operator overloading, etc. are great for
> abusing when you need something that's not universal enough to be in the core
> language.

Well I'm not so sure about that. In fact I'd go as far as saying you're 
contradicting yourself. The cruft and baggage is exactly left by 
unsuccessful language features that had to stay because, well, they were 
IN the language. For a good while, C++ has been rather liberal in 
adopting new and risky language features (exceptions, multiple 
inheritance, templates...) In contrast, for most of its existence, C++ 
has had an extremely thin library. An example of a bad library from the 
old days is iostreams, but hardly anyone considers that a major issue. 
It's not cruft and it's not baggage. It just sucks. :o)

So your own logic inexorably leads to a conclusion opposite to your 
hypothesis: it's best to keep the language lean and keep one's options 
open, lest cruft and baggage will accumulate.

Of course that, taken to an extreme, can lead to contortions and can do 
more harm than good. So moderation is likely the best way to go.

> The flip side is that, the more you rely on libraries (whether your personal
> snippet library or an "official" library) that use hacks like this, the more
> you're building a house of cards.

That's a bit odd. Are you saying that libraries are inherently less 
reliable than language features?

> When you build hacks on top of other hacks, and
> build these on top of still more hacks (think STL), you're basically asking ugly
> syntax, odd corner cases, and the exposure of obscure implementation bugs.  This
> is why things like arrays, strings and delegates belong in the core language.
> Since properties are just as universal, I believe the same argument can be made
> for them.

When I "think STL" I'm thinking of the best-defined library of general 
containers and algorithms. No other library I know goes to a longer 
length at defining its own behavior. Knowing STL makes me look with a 
rather critical eye at the loosely-defined libraries that accomplish 
(often sloppily) similar tasks usually featured with other languages.


Andrei