[aztec-devel] Re: Changing the way functions are handled

  • From: richard <rm.vaneijbergen@xxxxxxxxxxx>
  • To: aztec-devel@xxxxxxxxxxxxx
  • Date: Mon, 8 Jul 2002 20:28:14 +0200


Phillip Martin wrote:
> 
> - Move the managing of all the custom functions into AztecLib. This is
> so scripting has easier access to them

That's something I also wanted to propose some time ago.

However, I don't think AztecLib is the right place to move them into.
Personally I'm seeing AztecLib as the place to be for higher level 
classes (eg. meshes, materials, parameters, etc) but not for those 
functions because they're neither low or high level.. they're somewhere 
in between.. or so..


> - Change the calling of those custom functions from the front end to
> always go through the java script interpreter. This way, any java 
> script
> functions also written and loaded can be executed just like any other 
> function.

Same as above, this is something that would make Aztec so much nicer 
than it is currently (in program design)


> - Change the functions to optionally take a vector of 
> MParameterObjectPtr's
> as arguments to each function and to return an MParameterObjectPtr as
> a return result. This way, we can pass things into functions, and 
> since
> the java script interpreter already has the capacity to handle these
> classes, hopefully it wont be a lot of effort to handle mixing and 
> matching
> java script and c++ aztec functions.

Hm, it would be nice though if it also were possible to pass/return 
other classes/structures/variables..
That would make it much more flexible imho, but maybe I'm just talking 
out of my butt (excuse my french) because I'm not really into these 
MParameterObjects :)


> - Make it so plugins can add in their own functions at run time,
> rather that limiting that behaviour to the Aztec front end.

Sounds great!


> - Possibly move the java script interpreter into a separate dll,
> rather than residing in the AztecLib project. This serves no purpose 
> other than to
> cleanly separate the two, not that they aren't separate now.

Maybe the interpreter can be moved together with those functions into 
that dll?
(see above)



I've also got a suggestion that is not related to the stuff written 
above..

Currently the Linux version of Aztec is doing things in a non-standard 
way (when compiling).

I would suggest to change that by making use of autoconf and all of 
that stuff so you can ./configure [--prefix=/blah --blah=..], make and 
make install to build + install Aztec on Linux.
This would also be more reliable since the configure script can check 
everything needed to build Aztec, which means better compiling 
conditions (I'm not sure if I should say it like that) and less people 
complaining about compiling errors.

One thing left to think about is the installation directory.. where 
should it be installed by default?
(personally I would vote for /opt/Aztec )

Anyone?


- Richard

Other related posts: