Jump to content

  • Log In with Google      Sign In   
  • Create Account

Sir Ementaler

Member Since 09 Mar 2013
Online Last Active Today, 02:25 PM

Posts I've Made

In Topic: Test if an import succeeded.

11 June 2016 - 11:46 AM

Thanks. After your previous response, I actually visited the AngelScript to-do page and noticed what improvements you had in mind. Our team was discussing whether to adapt a similar approach, but for now I'll be trying something different. It's a similar concept, but rather than import functions, I'm importing interfaces. The exporting module registers a class C that implements a shared interface B, which in turn inherits from an application-registered empty interface A. It also registers a hook that returns an instance of class C. The importing module calls an application-registered function that calls the hook in another module and returns its result as a handle to A. This result is then cast to a handle of B, which is possible because it is shared. This way the importing module can call methods of an instance in another module.

 

This approach is not as straightforward as imports, but it has its advantages. It's safer, because a module may only import a selection of functions that are meant to be imported, rather than just any function it desires. On the importing side of the code, it often ends up shorter, because a single import gives the script access to all functions of another module (the shared interface B can be placed in a separate header file that just has to be #included). The most complicated part of code ends up on the exporting side, which I think is a fair price, because I expect modules that expose a functionality, akin to libraries, to be only written by the more experienced users.


In Topic: Go-inspired features in Angelscript

07 June 2016 - 06:18 AM

 

It makes it much harder to tell the type of a variable, its moment of declaration, and initial value.

The same kind of argument applies to 'auto', which found its way into AngelScript nonetheless.

Not exactly. The auto keyword has its flaws and a good programmer knows not to overuse it, but it has only one of the issues I mentioned, which is that it's hard to tell the type of a variable. It doesn't however, create ambiguity regarding the moment of declaration or initial value. Let me demonstrate:

auto x = 1;
x += 1;

Easy to tell when x was declared - there's a keyword in front of it. The line especially stands out in editors with syntax highlighting.

x := 1;
x += 1;

The lines differ only by one character. In a busy function, it could take a long time to tell whether x is local or global.

auto g = 1.f, d = sqrt(2), i = pow(2, 4), t = sin(3);

Easy to tell the initial value of each variable.

g, d, i, t := 1.f, sqrt(2), pow(2, 4), sin(3);

It takes some counting to determine which variable has which initial value. Again, this is a trivial example but in a real life situation where variable names and initial values were somewhat longer, it would become unreadable.

 

Even the type is actually easier to tell with auto, because unlike in short declarations, you cannot declare multiple variables of different types in a single auto declaration, so if you know the type of one variable, you know them all.

 

Again, I was asking for benefits of short variable declarations. I think a proposed addition should be supported by rationale.

 

C++ is my primary and favorite language and my team chose AngelScript largely due to its resemblance to C++. I also know several other languages, and although Go is not one of them, Lua is, and it has both of the features you're suggesting. Not a fan of it. I'd rather type more code and know what I'm doing when I return to it after a month.


In Topic: Go-inspired features in Angelscript

06 June 2016 - 05:15 AM

What are the benefits of short variable declaration? All I can see it doing is obfuscating the code. It makes it much harder to tell the type of a variable, its moment of declaration, and initial value. As a person who is often asked to read and debug others' code, I'd much rather encounter the current declaration syntax.


In Topic: Test if an import succeeded.

06 June 2016 - 03:55 AM

I see. Our application aims for high forward compatibility of scripts, so if it's awaiting a redesign, perhaps it's better if we currently resign of import altogether and try to use a more future-proof approach.


In Topic: Operator overloading with const instance of the class

27 May 2016 - 01:23 AM

It's only as wrong as it would be if you tried to do the same thing in C++. The expression 'constVec + vec1' is equivalent to 'constVec.opAdd(vec1)'. opAdd is a method like any, so it may modify the instance. The compiler can't know if it does, especially for an application-registered function, so by default methods are not available for const instances, just like in C++. But like in C++, you can easily enable them: "Math::Vector3 opAdd(float) const".


PARTNERS