I don't think the article is online; and I can't just type it up. It's copywrited, after all.

As for... well. Everything else. All valid points. I also like the level of control over the interface the scripts see that AngelScript gives me. As for the strong typing; inside C++, it's strongly typed. Inside the scripts, it's strongly typed. In between, damnit, the strong typing is a pain in the ass.

Also keep in mind that my analysis of the article is most certainly biased, and that bias certainly affected my choice of points.

Slightly off topic but i was wondering what you mean when you say wrapping? I am a beginner but ive seen this terminology around the site. A slight generalized explaination would be appreciated. Thanks!


TLD

wrapping - check the generic interface. Most scripting languages allow you to use your c/c++ functions from within the script itself. To achieve it, you usually need to write your function in a very specific way.

check "test_generic.cpp" to see it in action. The problem with wrappers, is that for each function you have, you need to create another function to wrap it so the engine can call it.

AS does it too (using the generic interface), but it can also work directly on the function (using assembly routines) and prepare everything (push objects to stack for example) to call native functions. It can save you a lot of time when trying to register new methods into the engine.

in the more general sense, a wrapper is something that will provide an easier to use interface to a complex or poorly written or logically similar group of functions.

For example, I might want to create a wrapper over winsock that easily allows me to send an http request. I want to be able to use it like this:

WinsockWrapper.MyHttpRequestMaker("this is my http post message");

The function would group together code that creates the connection, socket, and finally sends the data

I'll start out by saying that Gilad and Kunitoki have a couple of really cool projects going on. Let me know what I can do to make your tasks of implementing IDEs easier. Also, be sure to let me know when I can link to your projects from the users list.

Quote:
If you haven't read it, an article in Game Programming Gems 6 compares Python, LUA, GameMonkey, and... AngelScript! One of it's criticisms of AngelScript (beyond the authors obvious Python bias) was the lack of tools like these.

This is really great news. The word of AngelScript is spreading. [grin]

Even if it may not be all positive words (I haven't read the book) I'm still very excited to see one of my projects end up in a high-profile book like the Game Programming Gems.

I'll try to get hold of the author and ask him if I can post an excerpt on the scripting chapter on my site.

Quote:
It also has fond things to say about the other languages built in container types.

I do not want to add lots of built-in types, but I want to write standard add-ons that support similar way of programming as in other script languages. Take AngelScript's any type, I plan to take it out of the core library and instead include it as an even more powerful add-on, complete with overloaded operators so that it can be used transparently in numeric and string expressions, much like the typeless variables in VBScript and &#106avascript.

Quote:
All in all, though, I still think Angelscript has a bit more of a learning curve, mostly do to the 'low level'ness of it's interface. Angelscript deals in void*s and memory blocks. I'm working on that problem myself, though it's proving to be somewhat of an uphill battle against C++s static typing. It's easy to get from C++ to angelscript, much harder to go the other way.

Very true. I'll do what I can to minimize the work, but unfortunately I think it will be very difficult to overcome this problem.

Quote:
But of course, to really use it you have to use my whole library, and everyone seems to prefer doing it the hard way. :(

I'm sure people will start to use your library more as it and AngelScript stabilizes and becomes more mature. Also, so far there are relatively few people using AngelScript, and most of those are hardcore C++ developers, who usually prefer going as low-level as possible without touching assembler. Just be patient. [wink]

Quote:
There are no build in functions at all. ... I just hope WitchLord will keep it small and fast. It should stay an engine and not become a development environment.

My goal with AngelScript is to make the core engine. I have no intention to make a fully featured programming language with lots of built in functionality. AngelScript should be the compiler and the virtual machine, only. As much functionality as I can will be put in add-ons, like the script string.

Regards,
Andreas

Some ideas for the engine itself:

There should be a way to access all registered classes. Currently there is "GetMethodCount", but there should be some more functions. For example "GetObjectCount", "GetPropertyCount" and "GetMethodDeclaration".

In addition, I have an idea to solve the debugging issue (displaying object value). We should add another method to call for each object, to get the value of that object.

int RegisterObjectOutput(const char *object, asUPtr funcPointer, void* obj,asDWORD callConv);

For example, when registering the "string" object (using stl string type), we'll also register the following function:

void GetStringOutput(void* object,char* buffer,int length)
{
strcpyn(buffer,(string*)object,length);
}

pEngine->RegisterObjectOutput("string",asFUNCTION(GetStringObject),0,asCALL_CDECL);

And in the context, there should be another function:
int GetVarValue(int varIndex, char* buffer,int length, int stackLevel = -1);

So we can always get the value of a variable as a string (if the user had registered a callback function for it).

That way, when we want to display the value of a class inside the debugger, we call "GetVarValue" for that variable, which in turn, calls the appropriate function registered via "RegisterObjectOutput" (in our case - "GetStringOutput").

I hope I was clear. If not, I'll try to explain again.

Quote: Take AngelScript's any type, I plan to take it out of the core library and instead include it as an even more powerful add-on, complete with overloaded operators so that it can be used transparently in numeric and string expressions, much like the typeless variables in VBScript and &#106avascript.<!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br><br>I see myself soon getting confused between my own any type and yours. :) If you look in my implementation, you will see the 'isOfType' function. If this function took a string instead of being templated, it could potentially work for types declared in AngelScript as well.

witchlord: i agree with gilad, there should be more control when we deal with objects values. this will help a lot in making output for values of object's properties in the callstack when debugging: actually i don't know which is the best method, but gilad shown an easy way to support this.
in my ide, i choosed to have the engine embedded so i can achieve stuff like multiple running contexts each with it's own debugging facility. i prefer to have the engine embedded into the ide so the i could come up to have persistent contexts shared in the registered objects themself, supporting scripted gui objects that don't need to have a handlers also implemented in the script.

I agree that AngelScript could expose more methods to allow the enumeration of registered types and properties as well as the ones declared in the scripts.

I'm not sure I can agree, however, that AngelScript should have a method for converting values to strings. In my opinion this should be done in a layer above the core engine, by determining which type the variable is and then taking the value of the variable with GetVarPointer() and converting it to a string using the appropriate method. But I'll think about it some more before I simply disregard this idea.

I've uploaded an update (http://gilad.gsetup.com/ASIDE.zip).

Please download and post your comments. Readme.txt was updated a little bit. Please review it again.

I've started to work on some changes to the library in order to support object dumping, so use the included files to test (dll,lib,h) since the interface is now different.

Don't try to debug real code now, unless you compile it using the supplied version of AS. After we'll decide of a way to access objects, I'll release an update for the IDE, to be used with the original library.

For now, I'm just looking for some reviews and comments in order to update the IDE.

Gilad