sm-sorcery-bugs AT lists.ibiblio.org
Subject: Bugs for Sorcery are reported here
List archive
[SM-Sorcery-Bugs] [Bug 8539] read_persistent function
- From: bugzilla-daemon AT bugs.sourcemage.org
- To: sm-sorcery-bugs AT lists.ibiblio.org
- Subject: [SM-Sorcery-Bugs] [Bug 8539] read_persistent function
- Date: Sat, 2 Apr 2005 10:48:38 -0800 (PST)
http://bugs.sourcemage.org/show_bug.cgi?id=8539
acedit AT armory.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |grimoire AT sourcemage.org
------- Additional Comments From acedit AT armory.com 2005-04-02 10:48 -------
perhaps we can apply some sort of restriction on what pvars you can read, like
they have to start with the word 'SHARED'. Another idea is theres another
persistent variable EXPORTED_PVARS or something, and external spells can only
read variables listed there, another step further is a variable containing the
spells that can read the exported pvars. So a spell has to explicitly give
permission for another spell to read its vars. The closest OO analogy i can
find
is data accessor routines which basically let you see some subset of the
internal data.
Having a list of exported variables and spells that read those variables makes
it so that whenever you change the sharing spell its reasonably obvious that
you
have to update the spells you share to.
The only other thing vaguely like this is sub-depends, which means one spell
depends on another spell with a certain set of options, this (i believe) is
more
on the lines of having spells ensure they have consistent values with other
spells.
and of course if the values of one spell changes it might have to trigger a
recast of the other...
I guess my feeling on this is, we can either support it or not, but if we dont
then spells will figure something out on their own, then we'll go and change
something and those spells will break in a much worse way. So perhaps this
scheme will allow some controlled sharing of data rather than the anarchy that
may ensue if we refuse to support this.
Adding arwed to the discussion.
--
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
-
[SM-Sorcery-Bugs] [Bug 8539] read_persistent function,
bugzilla-daemon, 04/02/2005
- <Possible follow-up(s)>
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/02/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/02/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/02/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/21/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/21/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/21/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/21/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/21/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/22/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/22/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/22/2005
- [SM-Sorcery-Bugs] [Bug 8539] read_persistent function, bugzilla-daemon, 04/22/2005
Archive powered by MHonArc 2.6.24.