Re: [Cheetahtemplate-discuss] great stuff, but simple question

[Mike O. <ms...@oz...>]

On Tue, Apr 29, 2003 at 05:45:05PM +0300, Torsten Rueger wrote:
> I'd like 
> to share a little experience on this include/define/extend issue. As I 
> see it these are all different (and valid) ways of achieving the same 
> end. Let's call that end code reuse or sharing.

I'm all for code sharing; in fact, I'm a strong advocate of it.
But there's a third way you didn't mention, functional.
Cheetah allows you to #import standalone functions and $call() them.

My bias against #include has to do with the way people pass values
in and out of it.  Set some global variables before calling it, maybe
the include sets some global variables too.  Spaghetti code.  PHP Nuke
is a perfect example of this.  It's something I've tried to prevent 
from infecting Cheetah.  Function calls involve a discrete and
obvious set of arguments, and a clear return value.
  
Tavis wants #include present, and since he's Cheetah's inventor I
won't go against his wishes.  He points out that #include does some
things we don't have any other way to do, such as inserting raw
text from another file, keeping a frequently-changing paragraph in
a separate file (such as a "What's New" stanza) that might be 
maintained by another person with different file permissions,
eval'ing Cheetah code from a string, etc.  But he agrees with me
that passing many global variables to an include file is bad design,
and doing it for anything more than one or two small paragraphs
is worse.  For over a year we have asked include-happy users to 
describe a scenario where calling functions was inadequate and
#include was clearly superior, and we have yet to hear of any.

In Cheetah, a function can be in its own subtemplate: 
  ## new.tmpl  -- import as "#from new import new"
  #def new($arg1, $arg2)
  <LI> Item 1...
  <LI> Item 2...
  #end def
Two unobtrusive extra lines are the only things that distinguish
it from an include file.

> Now working with Designers and Html coders I have often found they 
> easily understand the concept of include. Even with changing Include 
> Paths or "$langage/template" kind of constructs. But this inversion of 
> control that goes with inheritance is something specific to the 
> (warped, not meaning that badly, IMHO) programmers mind. Programmers 
> frequently (mis)use inheritance for code sharing and it is just not 
> very clear what is going on when doing that. One needs to know the 
> implementation of the base class to understand, it's unclear. 
> Inheritance was invented to make it possible to work on a variety of 
> different types through the defined protocol of the base class, knowing 
> that each type will do with a message what it needs to. This is very 
> different from code-reuse if you think about it.

You are right that inheritance is overused in the OO world.  Many
people have found that containment (functions or subobjects) is not
inferior; in fact it's superior unless a specific need can be
demonstrated for inheritance.  Containment allows you to plug in and
out generic features without having to switch base classes, modify the
inheritance chain, or introduce esoteric features like Zope's
acquisition.

> Anyway, all I'm saying is that in my experience people, and especially 
> non programmers understand the include mechanism best.
> What all that talk boils down to is off course that it could be better 
> documented and multiple paths could be supported by default (with : 
> seperator, from a config or environment variable).

If it's a highly requested feature, or if Tavis feels like implementing
it, it will be there.

-- 
-Mike (Iron) Orr, ms...@oz...  (ir...@se...)
                       English * Esperanto * Russkiy * Deutsch * Espan~ol