Re: What to do with builtin functions not in libinterp subdirectory

[Daniel J Sebald]

On 03/18/2013 12:03 PM, John W. Eaton wrote:
> On 03/18/2013 12:50 PM, Daniel J Sebald wrote:
>
> > You are thinking then that the DEFUN family can remain in the code? Or
> > eventually change that over? I suppose it really isn't the use of the
> > DEFUN that creates a challenge; it's the macro pre-processing.
>
> Is it a problem if there is a macro that generates the class? It's a lot
> less typing and would keep the class definitions consistent. But I'm not
> sure I see the point of making this change. Using a class just trades a
> lot of mangled function names for a lot of classes in the global namespace.

I don't know the innards so well.  I think the base class and virtual 
function idea probably isn't the way to go now that you mention the 
global namespace.  I suppose it could just be a builtin class and have a 
function pointer as an element.


> Is the only real advantage that there is some automatic way of inserting
> the function pointers in the global table table of built-in functions
> without having to generate something like builtins.cc? I think you will
> need some kind of singleton object to achieve that without having some
> order of initialization problems.

Well, just brainstorming before embarking on a lot of work to 
incorporate GUI builtin functions using the DEFUN approach.  What I 
tried last night was simply too much work, if I could even get it to 
work.  To move the macro processing back a level, i.e., go from:

             MACRO PROC
libinterp->{subdirs}

             MACRO PROC
   libgui->fcn

to:

MACRO PROC
libinterp->{subdirs}
   libgui->fcn

may not be easy.  I don't think we want "fcn" as one of the {subdirs} of 
libinterp.  That means Qt code in that subdirectory, conditionals to 
exclude the GUI from compilation if configured, so on.  Furthermore, 
what I'm attempting is simple modal use of GUI elements, i.e., call the 
GUI which waits for user input then returns a string to Octave core. 
There could be more complex interaction with callbacks at some point 
which means utilizing Qt's slots and signals.  Lots to think about 
before diving in.

Dan