Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=13938





--- Comment #18 from Jaka Kranjc <svn AT lynxlynx.info>  2009-09-28 04:41:28 ---
1. Sure they do, they're switches for functionality even in your code.

2. And it would be good to add _hook suffixes to all of them, so they can't 
get
mixed up (in the functional approach).

3. But having the calls inlined will not change variable availability, except
for any clashing local vars of the deepest scope.

4. Spell files have no success/failure hook separation, just pre/post. What 
the
hook does can depend on the success/failure of the previous code, so perhaps 
it
would be good to pass the return status to it too.

8. I meant libhook, I didn't say hooks.

9.1. The file doesn't have to create any feature creep. Think of it as the
default hook constructor. The sorcery one would for example call the
$SORCERY_HOOKS/ counterpart to do any real work. That is if it is needed at
all.
With the function approach it would have only a hook container role, since the
sorcery one would just define the 2 or 3 default sorcery hooks then source
$SORCERY_HOOKS, which can replace, use or disable them.
(the two functions you moved there would remain where they were before)

10. First an unrelated comment: . */success won't source all the files, just
the first that expands and the others would be treated as positional 
arguments.
It would have to be done through a loop.

No, it would work as well. Let me explain it in greater detail. On sorcery
startup the sorcery libhook would be read, defining a few default real 
fallback
hooks (like with default_sorcery_build) and the rest as noops. Then all the
hooks under $SORCERY_HOOKS would be read. To make this nice and simple (no
contention), each hook function would have a prefix of the filename (eg.
dzen_post_SUCCESS_hook).

One way would be to check and use the functions per function and per bundle,
something like:
hlist="dzen"
[[ -z $hlist ]] && return
for fname in $flist; do
  f="function $fname () {"
  for i in $hlist; do
    if declare -F ${i}_$fname &>/dev/null; then 
      f="$f ${i}_$fname;"
    fi
  done
  if [[ $f != "function $fname () {" ]]; then
    f="$f }"
  else
    f="$f sorcery_$fname; }" # or just include it in the hlist
  fi
  $f
done
It is pretty much more of the same that we already do.

And like I said, this would be done on init, not each time. So after the
sourcing is done, the real hook functions would be already completely defined
and ready for use.

For kicks, the default sorcery post_SUCCESS_hook could reinit the hooks if a
new one was installed, so they would work immediately in the middle of
multispell casts. Not sure if that's a good idea though, it depends on what
kind of hooks there'll be.

10.1 Of course it is in the eye of the eye tyrant, but this is no excuse for
avoiding debate and possible improvements.

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.