gafter on master
Propose Feb 11 agenda (#2187) (compare)
What are you trying to say here?
Exactly what I said. An unimplemented feature is something the team has decided to do but hasn't implemented yet. This is something that has not been decided. It is not a feature, unimplemented or otherwise.
Asking why it can do this and not the other isn't quite as asking why it isn't there.
The answer to "why it isn't there" is always the same: because nobody has built it. That may sound glib but it's quite literally true. (See above, re: limited resources.) There has to be a very good reason to spend time and effort designing, speccing, coding, testing, and documenting a new feature. Minus 100 points is a good article for understanding the team's perspective on it; I'd recommend familiarizing yourself with the principle it explains if you want to ask for new language features.
@HaloFour The entire language. If you define a constructor on a base class, you can use it on any of its descendants. The place it gets really useful, though, is when you start working with virtual constructors. You can call a virtual constructor with a metaclass reference, pass in the parameters, and get an instance of the class in question.
As I mentioned on the Github discussion, this was largely put in place to support form deserialization. The DFM (form data) files have class names in them, and the RTTI system has something functionally equivalent to a string->metaclass dictionary for all of the Component types used in your program. So you take your class name, get a metaclass from there, invoke the virtual constructor, and you have a Component-typed reference whose actual type is the class you wanted. Use RTTI to fill in the properties, then repeat recursively on all the child components until you have your whole form.
It kind of depends. If you're a software company with a budget, that hardly matters.
What does matter, though, is when your software company can't hire any devs because no one knows how to use your programming language because they weren't taught it in school and didn't pick it up as a hobby because there were plenty of free alternatives available.
Training someone on the basic syntax and semantics is easy, if they're already a competent programmer. Training someone to know and internalize the idiomatic patterns of the language and be familiar with its ecosystem? That takes years.
I'm not sure years is fair. Months, sure. Years gets you the equivalent of someone who reads all the language design meeting minutes, and you don't need that to be a competent programmer. But the cost of hiring someone is measured in months' salary anyway, and you're getting some level of value before they're fully competent
It didn't help Borland that VB programmers were substantially more common and generally less expensive as well.
Yeah, that's the next step from my "what does matter," above. When companies have trouble hiring devs for your language, it makes them less inclined to use your language.