Metaclass with name overloading.

Carlos Ribeiro carribeiro at gmail.com
Tue Sep 28 18:38:30 CEST 2004


On Tue, 28 Sep 2004 14:37:31 +0200, Alex Martelli <aleaxit at yahoo.com> wrote:
> Carlos Ribeiro <carribeiro at gmail.com> wrote:
>    ...
> > Generic templating mechanisms start as simple variable substitution
> > engines, but as they start to be used, there's the need to add control
> > structures (if, for, etc); it's also needed to provide more ways for
> > the template to communicate with the main program, exchanging
> > variables and values. At this point, wouldn't be better to write all
> > templates in the main programming language of the system?
> 
> At this point, your templating is not declarative -- it's imperative.
> Like everything in Python, btw -- not ONE 'declarative' in sight (except
> the 'global' statement, which is part of what makes it a wart;-).

I knew I should have taken more time to write that paragraph :-) The
way I'm writing my code "reads" more like declarative code than
imperative. One can surely argue with my lack of academic rigour. I
think that I'm writing "declarative" code because I'm using class
declarations to create complex, hierarchic data structures. I want to
state __what it is__, not state __how it should be done__ step by
step.

Your comment also made me realize a point that should be highlighted.
Normal templates [1] are clearly imperative, and that's part of my
problem with them. But complex object-oriented structures, although
including code (in the form of methods and descriptors) are much more
dynamic than a simple template. Better than this -- normal templates
are inherently sequential and imperative in the way they're written.
Object oriented structures are much more flexible in this respect.
 
[1] I stress the term "normal templates" because I'm focusing on
standard, run-of-the-mill templating systems.

> There IS a case for purely declarative stuff _embedding_ Python code,
> like strakt.com's "blam" (purely informal name, as Strakt's marketing
> may lot like it, we just can't keep saying "Business Logic Module
> Language" forever;-) does for (basically) ERD + actions/triggers.  The
> embedding makes the whole non-declarative, of course.  But the
> declarative part can still be way prettier than it would be if it wasn't
> a separate language, e.g. it could use such keywords as 'entity',
> 'relation', 'attribute' and the like...

In the end, you've raised another interesting point -- on the whole,
my current approach is not purely declarative. It's rather a mix of
imperative and declarative, but with a mostly declarative
infrastructure holding things together.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com



More information about the Python-list mailing list