| MrDunne |
07-01-2011 08:13 PM |
Quote:
Originally Posted by cbk1994
(Post 1656926)
It would certainly be easier to do that, but I think ultimately GScript would be better if it had used a strict system. Keep in mind:
On that note, I've proposed JS-like prototypes for GScript multiple times and would love to see them added.
|
I still don't buy it. Keeping backwards compatibility and adding a class-based system on top of it sounds like a really bad idea.
The main reason being is that's the main path C++ took and it's a horrendously complex language. There's an old saying but I can't remember it but it goes something like once is a tragedy but repeated again is a fallacy. It's essential repeating the mistakes of the past but even worse so because you have 2 object systems on the go (you know, for backwards compat).
Why 2? Well, Graal has an object system which has features which are distinct from that of a class-based system. I think you know what I'm talking about : you can create a base object and join some classes to it. You can then clone that object and, if I remember rightly, the members will remain. This isn't very classical.
To gel the two together, like C++ OO was squeezed on top of procedural language, you'll be doing something similar but squeezing one OO type onto another OO type. Bad news.
That's just my take on it anyway. Maybe what you have in mind is a lot cleaner? I just envision seeing a load more keywords being brought in that must be learned and kept track of. |
