Re: [Cfengine-develop] Re: Homework

[Chris (Ducky) Chapin]

On Tue, 4 Mar 2003, Luke A. Kanies wrote:

> # this would be a list...
> processes = ( $sshd )
> 
> links:
>   each(@processes) {
>     /etc/init.d/$_{pattern} -> /etc/rc$_{runlevel}.d/S$_{runpriority}
>   }
> 
> processes:
>   each(@processes) {
>     $_{pattern} restart=$_{restart} useshell=$_{useshell}
>   }
> 
> #------------

I'm very keen to stay away from imperative style as much as possible so
the user/admin is always thinking in terms of what is to be managed, not
how to manage it. So, to me, the foreach just doesn't seem to fit quite
right.

Working backwards a little, I kinda like the way list expansion works in
the cfengine2, but I'd like some backreference support. To take your
assoc. array, and just change the links processes:

===

links:
   /etc/init.d/$(processes) -> /etc/rc$($(1).runlevel).d/S$($(1).runpriority)

processes:
   $(processes) restart=$($(1).restart) useshell=$($(1).useshell)

===

Where $(1) gets populated on each iteration, $(2) would be the 2nd list to
be expanded, etc. Sort of like RegExs, I know, but the variable isn't
important to me, the function of it is, so please improve it =)

What I don't like about the above is it's still ambiguous as to where the
expansion happens - or maybe I'm blowing that out of proportion.

Glancing at the code, the "$($(" also looks a little weird, too, but does
make sense.

> You get the idea; there are details associated with a given concept or
> object which are needed by multiple sections in cfengine.  Currently,
> those details all need to be maintained independently, and we have to fake
> separate namespaces by prefixing all variables with a string, and then we
> have to man set up each section to look for the correct info for every
> separate object.
> 
> Associative arrays are the next best thing to objects, and they give us
> that separate namespace capability, allowing us to unify all of the
> information about an object, and then use that info however we want later.
> 
> Obviously, the syntax was just a way to make a point; I'm not specifically
> recommending that syntax....

Associative arrays would be nice, since I'm not going to want to write or
wait for someone to write a plugin for EVERY task that comes up that
doesn't already have a predefined handler.

-Ducky