That would be misuse. You add the reference to the object that the id points to.

Assuming the language chosen is C++ , then use the smart_pointers.

I wasn't disagreeing about reference-counting.

So the id points to an object which contains pointers to the objects you want? I don't see how this indirection makes anything easier to use. It's just pointers again.

You could have rolled your own. I've been using my own smart pointers for many years, but now I am gonna throw them out and use the standard ones.

I have mingw 4.8.1 and it works superbly so far.

Exactly like a pointer then. For example, this:

gui.q("#main_menu button#start_game").click([&game, &gui](E)...

Is exactly the same as this:

main_menu button->start_game->click([&game, &gui](E)...

when it comes to resource management: in both cases, if the target object is not there, an exception can be thrown.

The abstraction you describe doesn't offer anything for resource management. It offers gui scripting though.

Sort of, at least in that particular example.

jQuery uses an expressive query language that always returns an array of matched objects. e.g., Something like the following would set the background color of every button to red.

jQuery("button").css("background-color", "red");

If there are no buttons, the code does not throw an exception because it's not an error. Nothing happens.

No, not quite. You can catch BAD pointers (corrupt, dangling), not just null pointers.
that's the benefit of the id. No runtime segfaults from bad pointers.
Anyhoo...

The id is not a simple index lookup.
It's encoded with other info specifically to catch bad pointers:
-active/inactive flag
-generation counter
-etc.

Of course this comes at a performance price. I was simply admiring E18.
But it's a complete development framework, so an object system is a worthwhile investment.
You could argue not, in our case.

Scripting is a very simple concept: code as data. That is basically all that scripting is. You do not need that for this to be useful.

Imagine this:

Gui gui("gui.xml");
GuiQuery q = qui.q("<syntax to be defined>");

q.value("This was a triumph.");

q is an object of type GuiQuery (for short, but it's really a query and a result). No matter what you pass into Gui::q you will always get a GuiQuery back. The GuiQuery contains zero, one, or many widgets that match your query. The GuiQuery contains a large set of standard interface methods to interact with widgets. Event binding and triggering, styling and layout, data storage, child management, etc. Basically you can do everything you would do to a widget through the GuiQuery. When you call a method on the GuiQuery the appropriate action is taken on each widget that matched the query. If no widgets matched the query then no action is taken. No exception is thrown. Nothing happens.

This allows your code to be very safe. You can add and remove widgets on the fly. It all just works. You can even do lazy binding and apply event handlers automatically to widgets that match some query when the event actually fires. That way the widget doesn't even have to exist when you bind the event handler.

These are some of the things that jQuery accomplishes, and it works very well in practice. It allows you to very efficiently express ideas across your entire UI, and it fails gracefully. I really think it is something that should be translated back to desktop (or, as the case may be, game) GUIs.

You're confusing ideas. There are data variables that store virtual memory addresses. These are pointers. These are low-level and unforgiving. Do the wrong thing and your program is terminated, or corrupted, or whatever.

I believe that what Pho75_ was trying to say is that in a way a "symbolic reference" like an "id" (of whatever type) is like a pointer in that it refers to something else, but unlike a native process memory address it can be easily validated at run-time to guarantee that it is good or bad. You can verify that the "id" exists. If it doesn't exist you can choose what to do in response to using it.

Obviously if your API allows the user to manage raw memory-address pointers themselves then the API can't guarantee that those are valid. However, the API really doesn't need to let the user manage those directly. That can be abstracted away from the user. And even if you do consider it useful to expose that unsafe part of the API, you can push a safe part of the API to be used for best practices. And it becomes the user's choice to accept responsibility (just as using smart pointers would be, except with smart pointers the user can still shoot themselves in the foot). You can instead expose something high level that the API can guarantee is always safe.

I simply disagree with these ideas. I want my errors to be visible as soon as I compile my application. If the widget is not there, I want the compiler to tell me that. If my widget is used erroneously, I want my compiler to tell me that.

The time and money saved by static compile time checking simply makes these kinds of ideas not worthwhile to me.

You can verify that your id exists as long as your variable that holds the id value is not corrupted, or the hash table that holds the id information is not corrupted.

That's not how you present it to me. You wrote the following piece of code:

gui.q("#main_menu button#start_game").click()

That's a pointer access right there: the function qui.q() accesses a pointer in order to return access to an object.

And since we are talking about untyped interfaces, the object that gui.q() returns will dispatch the click() call to an internal object via a pointer again.

You can't do that in an unsafe language.

I DO work on my gui, as well as posting.

Well I have been cleaning up WidgetHandler, allowing the user to set the root layout for the container. Now I am working on my Grid layout. It has the option to fill the cell or align to the cell only as well as to set a horizontal or vertical gap and horizontal or vertical cell padding.

How do you guys prefer drawing layout containers? If at all. But consider how they would be drawn - do you use virtual callback functions to draw them based on your preferences? So you can override the drawing in a sub class and then use that as your layout container? Or so you can draw widget backgrounds and nine patches in a derived widget? That's one way I could allow the user to customize my gui. So they can specify their own drawing routines or leave it and use the default ones or use both draw the base class first and then decorate it.

After Grid layout is Flow layout. Every layout has a halign and valign property, unlike Java cough&. You also couldn't leave empty grid markers, which sucked.

Later on I will write GridView and Table and Pin layout.

edit - I mean cmon, the JDK must have literally hundreds to thousands of contributors, surely they could have come up with some better default layouts?

You cannot account for memory corruption. Unless that memory corruption is by design. You don't seem to be capable of understanding our conversation.

I'm not at all arguing against smart pointers. They are a very good thing, and I use them myself whenever I write C++. That's entirely beside the point.

I'd prefer an API that didn't even require me to manipulate pointers directly. I want a higher-level abstraction that lets me express what I want without having to manage all of the language semantics. C++ is plenty capable of doing this, and while there needs to be ugly and unsafe code, the ugly and unsafe code can all be centralized and written once and hidden away. It's essentially the same concept as a smart pointer, but at a higher-level.

There will always be bugs, but over time those bugs can get found and fixed and it will stabilize. If you wrap all of the ugly and unsafe code up into a safe API then you can guarantee a safe library. The alternative is worse: leaving the user to manage the unsafe code themselves, in each and every program, so the number of bugs will be exponentially higher and never cease.

Pointers are not the enemy. Pointers are not dangerous. Invalid pointers are dangerous. Correct code does not have invalid pointers. Pointers are an inevitability in any program, whether you know about them or not. However, pointers can be wrapped up into safe black boxes to separate your program from the error-prone work of managing pointers. That's essentially what interpreted languages do. Smart pointers are still pointers. They're only as correct as the user is setting them up.

What you describe is a memory leak.

And now you're agreeing with me again.

I could say the same thing to you.

What do you guys think? Are virtual callback functions the best way to decorate and or draw widgets through inheritance? What about function pointers? Passing functions to use? Or make widgets fully re-implement the draw function? If I use virtual call backs that is one easy way to change the way an object is drawn, by a quick subclassing of that widget.