class extensions

[Lutger]

kris wrote:
...
> 
> And it potentially introduces additional namespace issues, hijacking 
> issues, and compilation errors for large and/or long-term software 
> development projects. The commercial-development space is where D ought 
> to target, if it's to rise well above being just another enthusiasts 
> playground :p

I agree, although I am that enthusiast. The main reason I liked this 
feature is 1) see Jarret's post and 2) I find it is easier to write 
small classes and extend them with free functions, good class design is 
hard. But if there are such issues then it is probably not worth it.

> A conservative approach would remove the existing idiom with arrays, 
> rather than propagate it, and address concerns instead by perhaps 
> looking at alternate approaches for supporting 'properties' (C# for 
> example). Are you thinking this makes a good solution for 'properties' 
> in general? As has been discussed recently?

No, not for properties. I never think of the current way properties are 
handled really as 'properties' in the sense of data members. They are 
just an alternative syntax for functions with 0 or 1 arguments in my 
book, with perhaps a hint to their role in a design.
Now this is my opinion, maybe misinformed, but I don't think class 
properties are important. They are just dressed up getters/setters, 
which is not so good an idiom to use frequently.

> Just because some folks apparently like it, and are vocal about it, 
> doesn't necessarily make it "generally appreciated"? That's a problem 
> with newsgroups and forums though ... it's perhaps easy to get a skewed 
> perspective?

Sure, although I have never seen one single post that objects to array 
properties, nor have I encountered bugs / problems related to it.

> As for extending to other types, that's cool! I just feel this 
> particular idiom potentially builds smoldering fires larger than the 
> one(s) it is attempting to extinguish (or perhaps it's not even trying 
> to resolve anything?). If that is the case it is hardly an adequate 
> resolution, and will simply return to bite D in the buttocks.

My impression was that it is mainly for syntactic sugar, and maybe there 
was a notion of how it could be used in generic programming? Can't think 
of an issue that it solves.

> As such, I suspect alternatives should be given great consideration (or 
> /greater/ consideration) and the relative trade-offs should be weighed 
> appropriately. Yourself, and others, may feel that's not necessary or 
> has been adequately performed already? I don't feel that way, and it's 
> not the impression I got from the conference :-D

No I don't pretend to have thought through the issues, I don't think I 
can. That's why I asked you!