I don't mind either way. Holding pointers to resources in a variable or getting an id to stick in a variable, makes no difference to me.

Ok, I've coded 3 implementations, compared them, and thought through the implications of each, and right now I'm going to go with either the existing ID system, or dumb handles (the only difference is in who allocates the 'ID', you or the system).

For intelligent handles, there are the two methods of Diggsey/Ben, and mine.

I found no benefit to using the Diggsey/Ben method over using standard ID's - existence-checks are replaced by 'is the handle valid' checks, there's a constant overhead for adding/removing handles from internal resource lists (they get copied and destroyed whenever you pass one into a function), and there's a memory overhead on a per-handle basis, and then you still need to manually delete the resource when you are done.

Although there were benefits to the scoped handle method I suggested, there was one great big problem with it - global variables, by definition, never go out of scope, so if a handle is stored in a variable at that scope, the resource is never deleted automatically, and can only be deleted by assigning a 'null' handle to the variable, and then you need to provide a function to check if the handle is valid. At this point, you're in a worse position than other methods, because sometimes you leave it to the system, and sometimes you don't and a beginner will make mistakes with that. In addition, it's kind-of counter-intuitive in a beginners language to use variables and not commands for controlling resource lifetimes.

Basically, all the new suggestions are pants, and we should stick with ID's.

Code is available for all three via email on request (it's quick-n-dirty code just to check things out, so don't expect too much).

I'm still not sure I see the problem with Diggsey's idea of deleting a resource automatically null-ing all references to it. In non-fictional code, you'll only hold a single reference to an object which would normally be in a UDT of some kind, or in a global variable called 'skysphere' or something.

The only difference I can see from using integers and an actual resource type using the above method is that this would be less prone to errors. In DBPro, you can delete a resource and all references to that ID would still remain, not to mention checking for its existence isn't a decent way to determine if it's been deleted or not, because a new resources with that ID could have since been allocated.

That's a bit of a minor issue, because as mentioned above, you'd only typically have a single reference to each resource, but it also means functions cannot discriminate the input resource type. Meaning it would be perfectly possible to pass a bitmap ID to a function expecting an image, and if an image exists with this ID then the function has no way of knowing if you made a mistake.

As a result of the above, you'd almost force Hungarian notation on either the arguments or function name. So I don't really see the advantage of using IDs, and introducing a garbage collector is a whole different story, as DBPro pretty much acts exactly like native C++ in terms of memory allocation.

I vote for the system to keep track of IDs. Who wants to set out variables and arrays to do all of this. Just let the system manage this and we are good.

@dark coder,

Taking Diggsey's/Ben's suggested handle mechanism:

Yes, you yourself would likely hold a single handle to a resource, but then you pass it to a function that you have written or even a TGC-provided command: now the handle has to be copied and now you have two handles (or more if that passes it to another function). Now you are into multiple handles per resource, and that has a cost in handling the addition and removal of those handles to the resource's internal list of handles as those handles are created and deleted.

In the code that I have thrown together, I can make it cheaper to add and remove from the resource's lists, but only at the cost of tripling the memory usage for a handle to 12 bytes each, thus making it more expensive to pass those handles around in the first place.

The only answer that I have is that dealing with handles in this way is more expensive than ID's, and has no clear benefit over them that I can see.

That's separate from an unintelligent handle, which has a type distinct from the languages other types (so an image handle can only be assigned to another image handle). That would be a cost-neutral method of using handles over ID's.

Yes, you yourself would likely hold a single handle to a resource, but then you pass it to a function that you have written or even a TGC-provided command: now the handle has to be copied and now you have two handles (or more if that passes it to another function). Now you are into multiple handles per resource, and that has a cost in handling the addition and removal of those handles to the resource's internal list of handles as those handles are created and deleted.

I thought we were talking about AppGameKit itself here, why would the C++ back end need to be integrated with this handle system? A call to PasteImage() for example would only require a read-only image, as there's no way you could delete it during this call. The only exception I can think of is assigning resources to other resources, such as the Sprite() command or TextureObject(), but such things could trivially be done using a simple resource counter combined with the AppGameKit handle list.

Sure, passing a resource to an AppGameKit function would require another handle list entry, but realistically this isn't going to be done during runtime, and I think you're making the overhead seem more significant than it is.

That's separate from an unintelligent handle, which has a type distinct from the languages other types (so an image handle can only be assigned to another image handle). That would be a cost-neutral method of using handles over ID's.

This should at least be in there as a given.


I think your reference counting suggestion would make the syntax a bit too different from DBPro, as the resource deletion commands would no longer be required. But there's an alternative to this that would combine both suggestions:

Inside the internal Image class there would be a boolean that specifies if the image exists and there would be a reference count(these could be mapped to just use 1 byte), so any operation like PasteImage or ImageExist or maybe just 'if myImage then' would first check if it existed. Calling DeleteImage would free the image data and set the boolean to false(thus all image commands on this resource could be set to raise an error). Then once all handles are reassigned or nulled, the ref count would reach 0 and the class itself would be freed.

Yes, you yourself would likely hold a single handle to a resource, but then you pass it to a function that you have written or even a TGC-provided command: now the handle has to be copied and now you have two handles (or more if that passes it to another function). Now you are into multiple handles per resource, and that has a cost in handling the addition and removal of those handles to the resource's internal list of handles as those handles are created and deleted.

Are we talking about reference counting here? Because if we're not, I don't see why each resource would need to know what's referencing it. Even if we are talking reference counting, the resource doesn't need to maintain a list of handles to it - only how many references it has. One byte is quite enough for this. Also, I had assumed that by passing a handle to a function, you'd be passing a reference rather than doing a deep copy. I must have missed something obviously.

Either way, I vote for handles. Not just any handles, but pointers to the resource. Yeah this can be dangerous if you give the user too much control over them, but they don't need that much control if they don't plan on doing any fancy pointer arithmetic or anything. Reference counting would also be nice, but that raises two problems: circular references, and the fact that users aren't really that sure when their resources will be freed. Manual reference counting is a good solution, but not exactly intuitive to novices.

Diggsey and I were discussing types of handles - I was advocating reference-counted handles (which I later back off of due to the issues you raise), and he was advocating handles that when a delete was carried out against one, all handles pointing to the same resource were also cleared automatically.

See the download in your thread, particularly the readme, which contains a rough performance comparison of all 'intelligent' handle methods discussed.

(BTW, if reference counted handles could be made to work, it'd be hands-down the winner).

Oh do you go off-topic fast or what!

Here's another vote for removing spaces. Case insensitivity gets another vote here as well.

And can we please not have object/sprite/sound ID numbers? When you code anything bigger they need extra code to work with.

My vote:

Please nooooo spaces

Also, Commands(x,y,z)
Case insensitive

Blocking can be {} or if endIf..etc as long as there's no spaces between words.

I also prefer dot punctuation when accessing members as opposed to /.
Sprite.x not sprite/x

Just covering all bases since TGC is re-evaluating syntax

No white-space in commands please, extra garlic and a side of fries to go please.

Do you want coke with that So it's definitely no spaces, which is just as well because the current AppGameKit compiler has zero spaces and works nicely too! As to ID removal, AppGameKit will allow you both approaches:

LoadImage ( 1, "hello.png" )
CreateSprite ( 1, 1 )
SetSpritePosition ( 1, 50, 50 )

Or:

yourimage = LoadImage ( "hello.png" )
CreateSprite ( 1, yourimage )
SetSpritePosition ( 1, 50, 50 )

Or even:

yourimage = LoadImage ( "hello.png" )
yoursprite = CreateSprite ( yourimage )
SetSpritePosition ( yoursprite, 50, 50 )

Also, it's also another good example why I prefer not to pre-declare my variables. I cut and paste my variables a lot to avoid typos and I can knock out this code two lines quicker than:

yourimage As Integer
yoursprite As Integer
yourimage = LoadImage ( "hello.png" )
yoursprite = CreateSprite ( yourimage )
SetSpritePosition ( yoursprite, 50, 50 )

As a side note, we're adding a compiler flag to force pre-declaration of variables, switch-able in the IDE so everyone gets what they want

Lee:
Wouldn't it be fantastic if AppGameKit suported this method of declaring variables, it saves a lot of time and space:

integer yourimage, yoursprite

I would also like to use "int" instead of the whole word "integer" everywhere. There's also "str" and "flt". Again to save on time and space.

You mean like C++?

Lee:
Nope, like in Lingo

I don't have much C++ experience but yeah, they also have that. Before DB I coded in Director 6 which used the scripting language Lingo. I used to declare global variables like that (global var1, var2, var3...).

Which would you prefer:

or


Here's another one for you:

or

Things to think about:

I think I would prefer this, all would be floats:

I certainly see why you would want to start shortening your declarations as they can get pretty vast! Maybe in the future we can add some abbreviations. My goal today is to protect the readability of AppGameKit and so although it's longer, it does clearly describe what is what:

A AS INTEGER : B AS FLOAT : C AS STRING

Right away you can 'read' what each variable type is, without understanding the magical symbols of FLT, INT, CHAR*, LPVOID, _INT64* and so on...

There are some space savers though if you're sticking with integer values such as:

TYPE leetype
a b c
ENDTYPE
lee AS leetype

This would define a type called leetype, and allow assignments such as lee.a=1 : lee.b=2 and lee.c=3. Admittedly not as easy to read, but a tidy way to create structures quickly (even quicker and shorter than C++), which would be:

struct leetype
{
int a;
int b;
int c;
}
leetype lee;

I think readability should win over possible abbreviations, and I am also guarding against adding two ways to do one thing as the result will be a wide range of AppGameKit code out there, only half of which everyone will be able to follow. Also the AS INTEGER style of declaration comes directly from DBP and has proved quite popular.

Lee:
DBP already supports:
GLOBAL var1, var2, var3

So why not at least add support for:
INTEGER int1, int2, int3
STRING str1, str2, str3
FLOAT flt1, flt2, flt3

Makes sense to me, and no abbreviations required.

And this would be nice as well:
GLOBAL INTEGER int1, int2, int3
GLOBAL STRING str1, str2, str3
GLOBAL FLOAT flt1, flt2, flt3

I just want it like DBPro.


Cheers.