If you could change one thing about GScript, what would it be?

[cbk1994]

Originally Posted by MrDunne

I kinda disagree here. I think pushing GS's object system more towards Javascript and prototypical OO would be far better. I think it'd be way easier going in that direction than going back and redoing it in a different style of OO.

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:

Originally Posted by cbk1994

Compatibility with old code is not a problem—even a change as drastic as strict typing is acceptable for this exercise.

On that note, I've proposed JS-like prototypes for GScript multiple times and would love to see them added.

[MrDunne]

Originally Posted by cbk1994

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.

[cbk1994]

By "compatibility is not an issue" I mean that for the purpose of this exercise, don't worry about existing code. Essentially, pretend you can make the changes before any code has been written. This was more for fun than to generate useful ideas for changes to be made now. Adding a strict class system on top of GScript now would be stupid.

[MrDunne]

Originally Posted by cbk1994

By "compatibility is not an issue" I mean that for the purpose of this exercise, don't worry about existing code. Essentially, pretend you can make the changes before any code has been written. This was more for fun than to generate useful ideas for changes to be made now. Adding a strict class system on top of GScript now would be stupid.

Oh so this is a basically "take GScript in your own way" sort of thing? Open up the VM and allow someone to write new languages on it. This is wishful thinking you. You'd need someone with the aptitude to do this (that's without taking into the "**** OFF" you'll get from the admin into consideration.)