Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Variable naming for sorcery variables (WAS: random y and n files?)

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Variable naming for sorcery variables (WAS: random y and n files?)
  • Date: Thu, 16 Sep 2004 12:56:30 -0700

On Thu, Sep 16, 2004 at 07:23:49PM -0000, evraire AT tuwg.com wrote:
> Hello,
>
> Quoting Andrew:
> > 1) before using a variable (even one inside a for <!--filtered--> in *;
> > loop), grep through sorcery for uses of that variable, if you find that
> > variable in use ANYWHERE in sorcery please "just say no", use something
> > more unique such as $SPELL_FOO rather than just FOO.
>
> It seems to me it would be useful to have a reserved prefix for sorcery's
> internal variable, such as "_SORCERY_". Using this example, the
> sorcery-specific variable "DEBUG" would become "_SORCERY_DEBUG". Thus
> spell-writers would know that their variable names are OK if they avoid
> using the prefix. Otherwise spell writers need to grep the source code
> everytime they write a spell, which makes spell writing more tedious than
> it need be.
>
> Also, new variables added to sorcery could conflict with variables of the
> same names in spells. In this case, the spell writer grepped sorcery to
> see if a variable was in use and it wasn't, so they went ahead and used it
> in their spell. A year later the same spell is used along with that
> variable when a sorcery developer adds the same variable to sorcery.
> Unless the developer casts that specific spell, the problem will likely go
> unnoticed during their testing. When the problem finally does surface, it
> will probably turn up as a bug against the spell. The maintainer of the
> spell might very well be confused why this spell would suddenly break
> despite never having been changed.
>
> To me, this sounds like trouble waiting to happen. As sorcery becomes
> more and more complex and more and more sorcery variables get defined, this
> problem will only become worse. I realize changing all the internal
> sorcery variables to a new nomenclature is a Big Deal(TM), but I think it's
> something we should strive for in the long run. To begin with, a
> nomenclature for internal sorcery variable names could be chosen and all
> new variables created can follow this nomenclature. Then, over time, we
> can convert the remaining variables to the new nomenclature.

Unfortunatly its not that cut and dry. We do everything we possibly can in
sorcery to have variables be local rather than global, but configuration
variables in particular (the ones in /etc/sorcery/config (and friends))
are not easy to just change on everyone's box (DEBUG is one of them). We
cant just decide one day to change all those because people would loose
those settings.

Its also not entirely easy to figure out what spells variables actually are
by grepping through the entire grimoire. Theres a log of relatively safe
uses of DEBUG in the grimoire. Sorcery is smaller and its therefore easier
to grep through the whole thing, or at the very least, /etc/sorcery/*

We've discussed having some arbitrary variable name shield for sorcery
variables but thats a lot of work :-/ and in a lot of places not needed IMO.

There are huge sections of code that have variables declared local and
never reconnect to spell files, and therefore really dont have anything
to worry about. Giving them ugly names is just going to further degrade
the readability as sorcery grows more complex.

Its only the places where we call spell files and the functions they
call where problems show up. For example all the downloading code is
almost completely shielded from spells because all the variables except
for a select few are declared local, and hardly any spells should be using
that code, same for gaze.

We try to declare everything as local that we can, that way if the caller
has their own value we dont trample it. Unfortunatly that doesnt save
us from spells NOT declaring something local and trampling on us, or
by using very generic names. We work around that partially by running
what we can inside subshells, this limits the damage spells can do to
the caller. However it gets ugly in CONFIGURE/DEPENDS when spells make
calls back into sorcery and we have to keep that data around (and thus
can't use subshells).

Sorcery is relatively small and the grimoire is huge, so its a difficult
situation in either stance, we could say sorcery should be more respectful
of spell variables and we'd have to grep through the grimoire everytime
we wanted to do anything, or use a huge ugly namespace shield, or we
could say spells should be more respectful of sorcery variables, but
then theres 1000's of spells to sort through...

I could go into great detail on what you can and cant do in a spell,
but i'll take the safer standpoint of suggesting that if both spells
and sorcery behave (declare local variables, etc) we wont have a problem.

You can put metal in a microwave in some situations but rather than
trying to explain to everyone advanced electromagnetic radiation,
they just say "dont do that!". So Im saying "dont do that!"

-Andrew


--
__________________________________________________________________________
|Andrew D. Stitt | astitt at sourcemage.org |
|irc: afrayedknot | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus | |
|Sorcery Team Lead, Porting Team Lead | |
|Grimoire Guru ham/smgl | ftp://t.armory.com |
|Author and Maintainer of Prometheus | |
--------------------------------------------------------------------------

Attachment: pgpZ3s3rNjrsz.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page