On Thu, 2007-03-22 at 23:26 -0700, Erick Tryzelaar wrote: > skaller wrote: > >> The q"..." form is a compile-time feature, right? I'm not sure that > >> could work for html templating, as that would have you dynamically > >> loading the strings from a file. > >> > > > > Make the file a Felix library, compile, link, and load it > > at run time as a shared library. The compile is only done once, > > flx already handles that. > > > > Export a function accepting an STL map and you're done. > > > > If you really want to do this .. otherwise of course > > you can easily write an interpreter. > > > > I don't think we should take that approach :) Someone like amazon or > slashdot wouldn't be able to recompile every time something changed. Or > if the string was pulled from a database or across a network.
Yes they can. We are talking about the Contents Management wrappers here not the contents. Compiling such a wrapper takes a few seconds passing it through Felix and C++ compiler. After that (a) it never has to be done again, because Felix checks if the binary is up to date (upgrade checks to use MD5 digests if the code is a string not a file ..) (b) the result is much faster than re-interpreting the framework with a lame interpreter every time (c) compile time errors will prevent some security problems arising from mistakes in the 'template' (d) the felix version can be FIBRATED giving thousands of times better responsiveness and performance So overall I actually don't agree. CTM's are based on the idea the wrappers are static with 'holes' for dynamic data, and it continues to make sense to compile the static portion and use typed variables for the dynamic parts, for the same reason compiled code is better than interpreters like Python or Perl: faster and more secure. > Sometimes I think felix has too much syntax. It makes it hard to, well, > add more syntax :) Yes, I agree, but as you know this is quite deliberate: the idea is to overload the compiler with so much redundant sugar that we're forced to find a way to move most of it out into the library by adding a higher level feature. So at this time, adding a specialised, compiler supported feature for some specific application domain isn't really a problem: I actually WANT you to do this, then try to remove it. I have difficulty thinking too abstractly, and remaining connected with the real world, so I favour use-cases as a model for driving refactoring attempts. Down the track I hope people will work on integration with Python and Erlang at least -- not just the usual embedding but also ability to generate C libraries for those systems as well as invoke their evaluators and transport data types across language boundaries. Erlang integration looks easier to do (it's much smaller and simpler than Python), however Python integration will probably get more people interested. The main problem with Python integration is .. well Felix can do most of what Python can do just as easily, more securely, and much faster. Whereas this isn't the case for Erlang, which provides functionality Felix does not have: the ability to transparently manage processes across networks. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
