Alex Schultz wrote:
Mark Wedel wrote:
Yes, all of this should go through a common code path, but saying those
checks
should be in the 'command' code may not be the right answer, depending on
what
the command code is defined as.
What I'm saying, is that 'character initiated' actions
Alex Schultz wrote:
Well, I'm thinking that we do have a BASECLASS, we might as well use
it for transitional fallbacks, OR better yet make a TRANSITONCLASS or
something, which the BASECLASS is based on. I would say that would be
just as easy to follow as things like apply_fallback() and in
Mark Wedel wrote:
Alex Schultz wrote:
Another thought, perhaps instead of the else though, we could use the
BASECLASS via another ob_methods structure as mentioned in a different
mail, to implement the falling back to the old function. Not only is it
well suited to falling back to the old
Alex Schultz wrote:
Another thought, perhaps instead of the else though, we could use the
BASECLASS via another ob_methods structure as mentioned in a different
mail, to implement the falling back to the old function. Not only is it
well suited to falling back to the old function, it IMHO
Mark Wedel wrote:
snip
In that mode, I still think it would be easy to do an object type at a time
-
you'd have something like:
ob_apply()
{
if (we have callback) do_callback()
else call_old_apply_function()
}
type of thing.
Yes, I agree and do now believe that doing
Alex Schultz wrote:
It may be better working on getting all of this infrastructure/callback
methods
in place, and implementing one type of object using them instead of focusing
on
the specific callback method (the web page mentioned doing all the apply
stuff).
Why? That way, if
Hello.
For a while now I've been throwing the idea of separating the server's
object-type-specific code by object types. Currently things are rather
disorganized with code for how an object type works being spread all
around the code. I plan to begin to implement the plan on the following
Alex Schultz wrote:
Well, the way I was thinking of doing it, would be to replace specific
calls to apply, drop, etc as they are sprinkled throughout the code, and
keep common code such as you say, in a common subdirectory of the
types directory, and then have the callback called by
Mark Wedel wrote:
Alex Schultz wrote:
Well, the way I was thinking of doing it, would be to replace specific
calls to apply, drop, etc as they are sprinkled throughout the code, and
keep common code such as you say, in a common subdirectory of the
types directory, and then have the
Alex Schultz wrote:
For a while now I've been throwing the idea of separating the server's
object-type-specific code by object types. Currently things are rather
disorganized with code for how an object type works being spread all
around the code. I plan to begin to implement the plan on the
Few questions:
Use form of server/types/foo.c or server/types/foo/bar.c depending on if the
object type requires multiple C files to be clean.
With the fact that the SVN repository is called server, it is unclear exactly
what server refers to.
If we include the repository name, is it:
Mark Wedel wrote:
snip
IMO, I'd prefer the second form - put the types directory at the top level,
relative to the server directory. This is how the socket code is, doesn't
have
any real disadvantage, but could have some advantages (better for unit tests?
Better for stand alone
12 matches
Mail list logo
