Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] spell file inheritance

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] spell file inheritance
  • Date: Mon, 3 Jul 2006 00:17:55 -0700

Only two points of clarification below:

On Sat, Jul 01, 2006 at 05:24:43PM -0700, Andrew Stitt wrote:
>
> Im working on bug 10914 and theres some additional spell api's that need
> to get created for it. I'd like to run this past the grimoire gurus in
> case theres something I missed, and to let everyone know whats going on.
>
> First some background on bug 10914, this is a hopefully more elegant
> and consistent alternative to the current method of extending spell file
> defaults. Currently a "default_foo" method is overwritten in FUNCTIONS to
> do extra stuff, then calls real_default_foo. For example default_pre_build
> may do extra stuff in some grimoires.
>
> With this enhancement sorcery will look for a section level or grimoire
> level file if it doesn't find a spell level file before executing its
> default (if any). Creating a section level file, accomplishes the same
> as creating the file in all spells. In addition to that, spells need
> a way to call their parent (just as spells call the sorcery default
> function already).
>
> I think that this inheritence scheme is a bit more aligned with the file
> based approach we use. Everyone I talked to so far liked the idea.
>
> The proposed api's will exist for every sourced spell file,
> except DETAILS (for now). Substitute "foo" below with "build" or whatever.
>
> default_sorcery_foo
> This would be the explicit function for whatever sorcery does by
> default currently (for example in BUILD this is ./configure ...; make)
>
> default_grimoire_foo
> default_section_foo
> These would source the grimoire or section file, or if they dont exist
> do the default behavior, which is to proceed to their parent
> (section->grimoire, grimoire->sorcery). If theres no section or grimoire
> file the sorcery default is called.

If a spell-level FOO called default_foo and it sees no FOO file at the
section level, does it go through to the grimoire-level FOO file that
may exist, or as this says, would it simply call default_sorcery_foo?

I'm just asking for clarification of "holey" hierarchy paths.

>
> default_foo
> This would simply call the parent from whatever step in the heirarchy
> is being executed. If you called it from a spell, it would go to the
> section, from section to grimoire, from grimoire to sorcery. In other
> words,
> spell files wouldn't need to do anything different than normal and
> spell/section/grimoire files wouldn't need to know where they are located.
>
> default_grimoire_foo would be useful for spells wishing to skip the
> section level stuff. Arguably default_section_foo doesnt serve any useful
> purpose, but I can't think of any other reason not to put it in.
>
> Parallel to these functions are real_default_*_foo versions behind libapi
> Overriding default_*_foo functions in FUNCTIONS before calling
> real_default_*_foo would still be allowed (although it should probably
> be discouraged by policy). This also makes the new stuff mostly backwards
> compatible. Might be a problem to call an over-written default_build from
> the section and grimoire BUILD files, though. Also it may be difficult
> coaxing this into working on previous versions of sorcery, so unfortunatly
> any uses of it may have to wait.
>
> Most likely the actual api's will be created at runtime while sorcery
> loads (to remove useless copy/past when adding a new spell file. So the
> definitions will leave libapi. A note will be added to libapi saying
> where to look for the list of spell files and their definitions.
>
> Anything obviously missing from this description? Is the explaination
> clear, at some point this will need to be documented so any help from
> the perspective of an api user would be appreciated.

s/perspective/prospective/

Seth

>
>
> -Andrew
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss




Archive powered by MHonArc 2.6.24.

Top of Page