Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] meta spells

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: Juuso Alasuutari <iuso AT sourcemage.org>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] meta spells
  • Date: Sat, 16 Dec 2006 17:42:07 -0800

On Sat, Dec 16, 2006 at 11:31:24PM +0200, Juuso Alasuutari wrote:
> On Saturday 16 December 2006 23:24, Andra?? 'ruskie' Levstik wrote:
> <snip>
> > Personaly I don't see a problem with approach 1)
> > Dependency tracking in dispel is still optional and I'm guessing it'll
> > remain that way for a long time.
> >
> > But I think one idea I've heard a while ago would be simply a function
> > that
> > wraps multiple depends into a single multi_depends. that way something
> > like:
> >
> > multi_optional_depends foo bar baz "--whavere-enable" "--whatever-disable"
> > "What does it do"
> >
> > Might not have the parameters in the same order but still I find this to
> > be
> > more or less the way to go...
> >
> > The problem is that sorcery would need to understand that if any of the
> > multi_optional_depends spell fails that option is disabled.
> >
> > I think this would be more with what we have. Personaly I can't stand
> > profile spells.
>
> I suggested that one a while back. It would indeed be very nice to have
> something like it. But the idea also got criticised for being difficult to
> implement (correct me if I remember that wrong). Sorcery would probably
> need
> to handle a thing or two for it to work, but IANASD (I Am Not A Sorcery
> Devel :))

Have we not hashed this out on the mailing list already?

If there's no way that fits with all the sorcery features, then an api
addition in sorcery might be needed.

Note that there's a difference between a grimoire function and a sorcery
function for the bystanders.

The design philosophy for sorcery as an engine is to be as minimal and
efficient as possible. It looks like this, with a view for design:

spells and spell functions (as specific as possible)
section libraries (as useful as possible)
grimoire libraries / convenience functions (as general as possible)
sorcery feature exposure api (as minimal as possible)
sorcery internal formats and algorithms (as efficient as possible)

I don't think we should be adding meta spells to enable what should be a
standard mnemonic for spell configuration. But what we need to do is
keep the interfaces between sorcery and the grimoire as stable and
minimal as possible. So if we're going to add something to fit with
this so that the sorcery engine for dispelling can be more accurately
dependency aware then it should be as orthogonal and minimalistic as
possible.

What I would do is accept your proposal for a multi_optional_* set of
functions, but what I'd actually rather see is a single set of code for
both single and multiple options. If we're going to split them out into
different functions they should get split in the grimoire libraries.

Note that your function api proposal as it is can't be implemented
because the arguments are ambiguous -- there's no simple way to tell how
many spells are specified before the non-spell arguments arrive.

Perhaps having all spells in a single argument, space-delimited would be
forward and backwards compatible, and we wouldn't need to add any
function names.

Andrew might have done some thinking on this issue already and might
even be able to summaries where we're at with past discussions, so we
should await his reply.

Seth




Archive powered by MHonArc 2.6.24.

Top of Page