Jump to content

  • Log In with Google      Sign In   
  • Create Account

InvalidPointer

Member Since 04 Apr 2007
Offline Last Active Today, 03:55 PM

Topics I've Started

Refactoring suggestions

14 January 2016 - 12:13 PM

Hey Andreas, long time no see! Since it looks like we're in a refactoring spell, I'd humbly like to submit some suggestions for (breaking!) API changes that would improve performance, readability, or both. In no particular order:

 

  • Is there a reason why RegisterObjectProperty()/RegisterObjectMethod() live in asIScriptEngine rather than in asITypeInfo? Not only would this drastically improve performance for more complex application APIs, (as we don't need to repeatedly look up the type) but the error handling could be radically simplified as we don't need to handle cases where the name string doesn't refer to a previously registered type, etc. This seems like a no-brainer and it looks like most of the infrastructure is in place anyhow.
  • What's the consensus about pulling asCGarbageCollector or something similar into the public interface? While I don't know if this would be practical in the general case, my engine project currently can currently run multiple game worlds concurrently and it'd be nice to have them all run garbage collection in parallel with one another. Likewise, there would be fewer individual objects in each collection which would improve GC latency over what we have now.
  • Building off the prior idea, what if we move the CreateScriptObject() family of functions into the proposed asIGarbageCollector interface?
  • Looking up functions by name/signature is *super* yuck from a performance perspective. Could we perhaps hash a combination of the signature and argument type ids to avoid the mega-gross linear search through all registered functions in the type? Is it even possible for the multiple matching function case to occur in practice?

As a final, long-shot bit, what are the odds of moving the project over to GitHub? Things like pull requests become super-easy if you're interested in accepting more community contributions. It's pretty cool! smile.png


Feature chat: Type/member annotations

07 November 2013 - 01:52 PM

While the compiler metadata feature has been around for some time, I've really been impressed by how powerful and elegant C#'s type/member annotation feature is. I feel we could cook up something pretty similar for AS using mostly pre-existing features (namely initializer lists and built-in arrays of interfaces) but for best results I really think this needs a solid, 'standards-compliant' official integration.

 

Brainstorming:

 

The actual creation/retrieval of metadata is pretty trivial. You'd probably want to have a basic (application-defined?) metadata interface stored in a built-in array. At a low level, the compiler could stow away anything in the square brackets, then parse the contents as an initializer list for your array. What is interesting is how the process would interact with bytecode precompilation, and specifically serialization. As of right now, there's no official AS object serialization framework, which means we can either A) develop something from scratch, B) create some sort of application interface (promising but obviously fragmenting/error-prone) or C) keep type metadata in plaintext, then parse it on bytecode deserialization.

 

As of right now, my vote goes for B; the differences between application interfaces mean that the loss of direct bytecode portability between AS implementations is essentially a non-issue. This also means that work/code could in theory be shared between the metadata engine and actual game functionalities like networking and/or game saves and thus be tailored to suit the needs of the specific use case(s).

 

Storing the metadata with the property/type is also going to be kind of interesting. I think keeping this as a script object makes the most sense, and I also think keeping the user data as a separate field is valuable. Therefore, I propose adding an extra void* member to store a pointer to the array. The pointer could then be cast as appropriate for use

 

The type would be fixed, and specifically the built-in array type with the subtype set to be references to the application metadata type.

 

Example application metadata type:

interface Annotation {};

Example AS storage type:

Annotation@[]

or alternately

Array<Annotation@>

For convenience, I also propose adding additional methods to asIScriptEngine with the following signatures

asIObjectType* GetMetadataBaseType() const;
asIObjectType* GetMetadataContainerType() const;

It may also be valuable to have different types of annotations for functions, fields and types, but that's what I'd like to interact with the library community on.


Delegates in AngelScript

17 September 2012 - 11:04 AM

Currently thinking about how delegates should work, as I find myself becoming really, really hamstrung without their inclusion in AngelScript. While I think I have some of the implementation worked out, I'm curious what people would want in an implementation and what the syntax should be. From a technical perspective, I think it's best approached at a single-subscriber level, with a delegate storing a function to call and an additional 'this' pointer; multicast delegates/events could be either a library add-on extending the built-in array type or something left to the application interface to provide.

What I'm not sure of, however, is how this should interact with garbage collection (as I understand it, this bites people in the ass with startling frequency in C#, do we need to have a language-level 'weak reference' construct too?) and cross-module function imports. Community, fire away.

Bytecode platform independence

03 December 2011 - 01:23 PM

I went to test my x86 project build the other day and the bytecode loader puked on me (I precompiled the source using a 64-bit tool) and I recall hearing something about there being some platform dependencies in bytecode yet. Twofold queston: 1) Is this still the case, and 2) if it is, where should I start looking to fix this?

C#-style property getters/setters

20 October 2011 - 04:27 PM

Just gauging interest in the concept, though I don't know what percentage of AS users frequent these forums. I've got a (second-generation, actually) implementation going that makes minimal changes to the actual back-end but makes a few enhancements to the parser/builder interfaces that let the compiler infer or generate function signatures on-the-fly. The net result is that you can now use the super-sexy C# property syntax like so:

In interfaces:
int TestProperty
{
	get;
	set;
}

AppInterface@ AltTestProperty
{
	get;
}

float AnotherTestProperty
{
	set;
}

In actual classes and/or global property definitions:
int SomeRandomInteger;

int AGlobalProperty
{
	set
	{
		// You even get the implicit 'value' parameter gratis!
		SomeRandomInteger = value;
	}
	get
	{
		return SomeRandomInteger;
	}
}

while still 'talking' to them via the bog-standard
AGlobalProperty = 50;
in external code. If anyone's interested, give me a holler here, but I'll probably just ship this off to WitchLord as soon as I work out a few parser kinks (for the interested, defining multiple getters/setters within a single property block doesn't fall-through quite as elegantly as I expected, the major result being some odd error messages) but at time of writing this does all compile and work more or less correctly. Next on the agenda is maybe using this to do some cool foreach trick :)

EDIT: I'll probably also make a few syntax tweaks to allow property getters to be optionally const, but I'm still thinking about how I want that to work.

PARTNERS