Would anyone miss stub and super?

Ok, I am seriously planning to do changes to the syntax:

* stubs won't work like they do rigth now anymore.
Instead, when you declare a method as a stub, the struct becomes a stub itself, you can't allocate it. And the stub method contains no code inside.

* Children can't ever overwrite their parents' already implemented methods.

* super gets removed (as it would be of no use, since children can't overwrite methods...)

* multiple interface extends is allowed (though due to the way it is going to compile, methods in the struct that is extending two interfaces will get a little slower than usual (an extra function call besides what they already have)

* Type safety gets added to the mix. So...
Will cause errors, I told you to use typecasts...

* You need .evaluate to call a method from above its declaration.

* .evaluate and interface/stub calls get topsorted to reduce TriggerEvaluate usage?

* Can use methods, natives and BJs in function interfaces.

* If you call an interface, stub method from create it works correctly, also .getType() ...

In other words, I really think I am rewriting the structs phase for good.

Yes i absolutely need super and overwriting methods. For example in the factory classes of my buff system there is no other way to go.

It would break everything in my map, if you remove it, so I would not use new jasshelper versions anymore. I don't want to learn delphi, to backport things to old versions.

Please don't destroy basic OOP features.

but type safety and multiple interfaces sounds cool.
Force evaluate is not nice for me, but it is ok and the right way.

But if you rewrite big parts of jh, wouldn't it be a great idea to topological sort functions?

I noticed I don't even use OOP in jass any more.
I did before because it was interesting to experiment, than I realized it is pointless in trigger oriented environment.

You could remove everything except globals, libraries and structs as far as I am concerned.

What is the point of having both stubs and interfaces?

Question: will it be possible for a stub struct to extend something? If so it would still be possible to add new virtual methods at a level lower than the top.

I have never wanted to overwrite an already implemented method anyway. I have realized that any time I wanted to use .super() it would be better and faster to move that logic somewhere else.

If you are doing topsort maybe you can eliminate the need for .evaluate in interface usage. in which case it'd still be relatively fast.

I have always been annoyed by the fact that you might accidentally use TriggerEvaluate without realizing it. This makes it a more explicit choice.

However, if topsorting works so well that you rarely need to use TriggerEvaluate, you shouldn't force using .evaluate() because it won't actually be any slower most of the time.

Or if the compiler is smart enough, only force .evaluate() when topsort can't figure out a way to avoid using TriggerEvaluate.


Can you post code examples of why you need super and overwriting methods?

/Agree. And maybe scopes.

I never got around to using that stuff, although it offers some interesting posibilities that interfaces alone don't (like declaring a stub method for just one branch of the interface tree rather than for the entire interface), so I don't really care.

If you mean this as a part of the rewriting structs project, if you are having too many issues with backwards compatibility you could just give the new and improved structs a new name (like classes or something) and eventually deprecate the original structs?

These are basically the only things that annoy me about the syntax, hence the reason I want to remove them. Adding 'classes' would be annoying.

Not using interfaces is sign of a big issue with the guy making the code, perhaps he needs to get rid of blocks that make him locked to broken mentality all for the sake of familiarity or there's something plain wrong with him. Worst case scenario he is Toadcop.

What's the point of .evaluate if things go topsorted anyway? Well, there are always cases in which just topsorting can't get rid of the TriggerEvaluate, so adding .evaluate will make you more conscious that something is probably not going "ok". In the case of functions it will prevent you from forgetting to add library requirements...

Good thing I am making maps than.

OOP paradigm is not inherently superior to other paradigms,
and it definitely is not natural/logical choice when it comes to wc3 mapping.

90% of the code is basic trigger-condition-action stuff

I dunno about that, the OOP of vJass is really helping me with my latest map, the map-specific code is pretty much all interfaces.

On the flip side I just ran into a weird interface bug that I just can't figure out even though I've narrowed it down to three lines of code. It might be a JassHelper bug, but I really want to be sure before I dump this mess on Vex.

If you've got it narrowed down to 3 lines of code you should pastebin it.

Actually, the bug wasn't in those three lines of code, which is obvious in hindsight.

The cause was actually some sloppy coding in combination with the lack of type safety on structs.

Do you think this is a good move when current JH/PJass pops error for it? If it allowed using .evaluate on the methods in the past then there would be less issue, but it hasn't been even possible; means there will be likely a compatibility hell. That's why languages, SDKs and IDEs rarely pop error for deprecated API/features.

You should consider something like putting their duplicate on top of the method call which you currently do with certain methods. When that's not applicable, make it show something like warning or notice when implicitly evaluated, not errors. You could do just warning message thing, if you want to save some time.

Also, there should be something like null for structs... structname(0) is way too long.

uhm, just to make sure: Making it impossible for child-structs to overwrite their parents methods won't change the way delegates work, right?

took a long time... but

+1