I would love to see some basic support for contracts (pre/post conditions) being available in upcoming versions of AS, as mentioned in:
http://sourceforge.net/tracker/index.php?func=detail&aid=1547663&group_id=161752&atid=821101
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
The future of AngelScript
Quote: Original post by paradoxnj
The only request that I have is that classes be handled like Java. Extend a class and implement an interface. For example:
*** Source Snippet Removed ***
This will make your life easier and provide a familiar syntax. It also will kinda look like UnrealScript. ;)
check the thread: if engine properties are to be implemented in the fashion that kunitoki proposed above, then a request such as yours would become a runtime property setting-where users could easily specify which syntax shall be used to begin/end code blocks or implement inheritance.
Deyja:
I'll try not to. ;)
paradoxnj:
I don't know about this. Not that there is anything wrong with the Java style, but for something like this I'd rather stick as close to C++ as possible.
Maybe in the future I can decouple the parser from the compiler, in a way that the syntax can be completely rewritten.
AP:
I don't quite understand the concept of contracts. I saw the post in SourceForge.net a couple of days ago, but haven't had a chance to respond yet.
Would you mind giving me a brief overview of how it works? That would make my life a lot easier than if I have to go look for it on Google or something. My time is short as always.
I'll try not to. ;)
paradoxnj:
I don't know about this. Not that there is anything wrong with the Java style, but for something like this I'd rather stick as close to C++ as possible.
Maybe in the future I can decouple the parser from the compiler, in a way that the syntax can be completely rewritten.
AP:
I don't quite understand the concept of contracts. I saw the post in SourceForge.net a couple of days ago, but haven't had a chance to respond yet.
Would you mind giving me a brief overview of how it works? That would make my life a lot easier than if I have to go look for it on Google or something. My time is short as always.
Quote: Original post by WitchLord
Thanks for the compliments. Is there a link to your project anywhere, that we can check out, and I can link to?
I'll check out the new standard draft. Thanks for the tip.
Regards,
Andreas
The link that used to be up has been removed, but it existed only to be accessible by our professors anyway. I won't put it back up, because although it was one of the projects I've had the most fun with, it was still a school project, with little value to anyone else. It was a traffic simulator, with scripted behavior. Also, it's 45 MB due to the use of the bloated Windows Bitmap format ;-). Sorry, I don't mean to give you any excuses, but then again, why would I wanna lie.
Good luck!
Basically, DbC means that your code may be associated with blocks that contain pre- and postconditions, that is the actual function body/code is ONLY executed if the precondition and postconditions match, so that programmers can ensure very well-defined behaviour for the code and basically guarantee that their code will only operate on data that it has been designed/conceived for, consider the following trivial example:
So programming languages that support "programming by contract" or "design by contract", allow programmers to define conditions that must be met in order to allow their code to be executed, and these conditions would be evaluated without anything in the actual code requiring to be executed first, so rather than an assert() or if in the code, contracts are separate.
For example:
int multiply_positives(int x,int y)
precondition: x & y must be positive
postcondition: return value must be positive
int multiply_negatives(int x,int y)
precondition: x & y must be negative
postcondition: return value must be positive
double divide(int a, int b)
precondition: b != 0
postcondition: none
Anyway, that's pretty basic-the possibilities are pretty broad,the following wikipedia link should explain the concept much better than anything I might come up with: http://en.wikipedia.org/wiki/Programming_by_contract
int multiply_positives(int x,int y){ return x*y;}int multiply_negatives(int x,int y){ return x*y;}double divide(int a, int b){ return a/b;}int main(){ multiply_positives(10,10); multiply_positives(10,-1); //oops: function was never intended to do that multiply_negatives(-1,-1); multiply_negatives(1,3); // divide(10,10); // okay divide(10,0); //not okay: division by zeroreturn 0;}So programming languages that support "programming by contract" or "design by contract", allow programmers to define conditions that must be met in order to allow their code to be executed, and these conditions would be evaluated without anything in the actual code requiring to be executed first, so rather than an assert() or if in the code, contracts are separate.
For example:
int multiply_positives(int x,int y)
precondition: x & y must be positive
postcondition: return value must be positive
int multiply_negatives(int x,int y)
precondition: x & y must be negative
postcondition: return value must be positive
double divide(int a, int b)
precondition: b != 0
postcondition: none
Anyway, that's pretty basic-the possibilities are pretty broad,the following wikipedia link should explain the concept much better than anything I might come up with: http://en.wikipedia.org/wiki/Programming_by_contract
and in C++ or rather a C++ oriented language it might look like:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1773.html#function-pre-and-postconditions
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1773.html#function-pre-and-postconditions
Todo:
No worries. I was just curious. :)
AP:
Thanks for the brief explanation. I have a pretty good understanding of how it works now.
It does seem like a lot of work to add this to AngelScript however, so while it might be useful, I won't implement it any time soon. At least not while there are other more useful features to be implemented first.
I'll add it to the todo list anyway, so it won't be forgotten.
Regards,
Andreas
No worries. I was just curious. :)
AP:
Thanks for the brief explanation. I have a pretty good understanding of how it works now.
It does seem like a lot of work to add this to AngelScript however, so while it might be useful, I won't implement it any time soon. At least not while there are other more useful features to be implemented first.
I'll add it to the todo list anyway, so it won't be forgotten.
Regards,
Andreas
Quote:
I'll implement single inheritance for classes. Script classes will be able to inherit from other script classes, and also from specially registered application classes. It will not be possible to inherit from just any application registered class (at least I've not been able to think of any solution for that yet).
why it would not be possible to register any application registered class ? i do not think that will be difficult, there was a patch posted here by Gilad that already addressed this stuff, even if simplified to the bone. if the problem is method invocation resolution i don't think is a real problem, just define a common way to resolve the correct function to execute when it could have the same declaration by traversing the object parent's registered methods/behaviours. or maybe the properties are the problem ?
Quote:
I don't think I'll implement multiple inheritance. The interfaces are already capable of handling most of the uses for multiple inheritance. Virtual inheritance most certainly wont be implemented, as that is a concept way too complicated and almost never used so it's just not worth it.
i agree with multiple inheritance, even if i use it a lot and would like to get my hand on a script engine that allow me to do this (but remaining as simple and easy as angelscript). for virtual inheritance is somehow too complicated to have it correctly implemented...
Maybe as I dig deeper into how inheritance will work, I may be able to find a solution to inherit from arbitrary registered C++ classes. But right now I believe it will cause a lot of trouble when the VM needs to determine the type of the object dynamically. Or when the script tries to pass a script derived class to a C++ function that expects the C++ class. We must also not forget the garbage collector.
We'll see what happens in the future.
We'll see what happens in the future.
you could implement it like this
x bytes type identifier
n bytes c++ class
i bytes derivative class
so if your call a class's c++ function your will operator on the n c++ bytes(this call convention
all other script functions should be trivial to implement
x bytes type identifier
n bytes c++ class
i bytes derivative class
so if your call a class's c++ function your will operator on the n c++ bytes(this call convention
all other script functions should be trivial to implement
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
