"Geir Magnusson Jr." wrote:
>
> [snip]
> And there are many examples (MSFT Win32) where that is done all the
> time, for example for threading support (beginthread()), Unicode support
> (tchar_t), etc.
Heh, referencing MFC isn't lending much support to your argument Geir.
;P
> My point is simply that the language gets richer for the end user in an
> end-user controllable fashion (they can add velocimacros) w/o making
> the language bigger internally.
The Right Way to do this is through the use of context objects--this
provides clearer definition of the separation between templates and
code.
> > > So the art major then sets up look and feel thing, and that is captured
> > > and formalized into Velocimacros, so his/her art minions can code the
> > > content templates. Then, when fashion changes, you can modify the
> > > velocimacros for a wholesale change.
> >
> > Who captures and formalizes it? Surely not the art major. I don't want
> > to have anything to do with that part of the process, I have way too
> > much work to do on various core engineering activities. Let's stick
> > with the KISS philosophy.
>
> Surely the art major! If the art major can decide, for example, on a
> given visual representation of something, and is able to use the
> template engine to express that, using all sorts of things like loops,
> including other templates, setting variables, checking variables,
> remembering that $!foo means #if($foo) { $foo } :) , then I believe
> they could handle defining a macro.
As anyone who has done it knows, using APIs is quite a different story
from defining reusable ones. I do not want my designers attempting to
define APIs.
> Surely someone, maybe not the core engineers, wants to prevent the evil
> menace of cut and paste?
Use of the context and #include can prevent this completely--no
Velocimacros are needed.
--
Daniel Rall <[EMAIL PROTECTED]>
