Public SourceMage Discussion List

[seth AT swoolley.homeip.net]

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