Re: Fluid Application Environment 3.0.alpha1 Released!
- Posted by jimcbrown (admin) Oct 14, 2013
- 2240 views
You seem to be asking for FluidAE to also be a preprocessor. There's nothing wrong with this, though this is typically outside the remit of a GUI toolkit. Still, I know that ryanj has plans to make FluidAE special, and maybe this is just one more method to make it stand out.
I must admit, I'm totally lost. I can't figure out what her requests have to do with FAE. They seem like another round of dynamic code execution ideas that would require a lot of changes to the guts of euphoria, regardless of what other libraries were involved.
Matt
Agreed. The only, and I mean _ONLY_, way I could see this last piece being vaguely related to FluidAE is if FluidAE was to include a preprocessor that simulated or emulated some of this stuff. Otherwise, it's a complete non sequitur.
FluidAE is a gui. How is using FluidAE to provide gui functions to an app a non sequitur? FluidAE handles what's onscreen and routes the keybd and mouse events, and handles message passing between the widgets, how is that not related to handling what's onscreen and routing the keybd and mouse events, and handling message passing between the parts of a program? Because you say so? Because you want to shut me up?
FluidAE providing gui functions to an app is not a non sequitur. FluidAE providing dynamic execution to an app is a non sequitur.
The goalposts seem to keep moving also - at first it seemed like the request was the ability to make minor tweaks to the library, then to add custom widgets, then to be able to deal with custom signals/messages, and now dynamic execution.
The goals are the same, the methodology of making it happen changes as you keep saying this or that method won't work.
In that case, let's change the methodology slightly more by taking a look at a version of the code that doesn't appear as if it is using dynamic execution:
procedure do_user(sequence what) if length(what) < 1 then return end if call_proc(what[1], what[2..$]) end procedure
Now, instead of passing in the name of the function as a string into the first element of the variable named 'what', the routine_id() from that string is passed instead.
If, in addition, you want to use the name of the function for some reason (e.g. metadata purposes, like printing out the name of the function in debug code if an error happens), here's a good way to do it:
procedure do_user(sequence name, sequence what, integer rid = routine_id(name)) call_proc(rid, what) end procedure
Then, in your code you can just pass in the name and stuff, without any need to call routine id directly.
