Re: [xsrcg-devel] Program Design Updates

[Max N. <max...@ya...>]

Le 16 juin 2004, =E0 08:55, Adam Brown a =E9crit :

> Okay, Jesse and I had a pretty long talk this evening on IRC.=20
> Hopefully we can all three get together there soon. Max, you might let=20=

> us know what time is good for you locally, since you're the odd one=20
> out, and hopefully Jesse and I can try and be around at that=20
> time...just a thought.

	I'm usually awake from 08:00 to about midnight GMT. I'm not =
always=20
online during that time, but if you want me to be I'll try.

(by the way, sorry for the apparent lag in my replies, but Yahoo Mail=20
seems to be having problems -- it took my last mail about 24 hours to=20
get to the list then back to me)

> On to the business portion now. We talked about a lot of stuff and=20
> eventually got into some good ideas on how to approach the program=20
> design. Both from a cross-platform standpoint and from a general=20
> design standpoint. We seem to agree that the best way to do this would=20=

> be to break away all of the back-end work into a separate library.=20
> There are several key advantages that'll get into below and neither of=20=

> us see any real drawbacks to this design.

	Agreed.

> First, speed. By breaking the guts of the program into a self=20
> contained library we can write it in pure C and do it with a minimal=20=

> of fuss. This will give the workhorse part of the program a good boost=20=

> in speed and efficiency.

	I'm not sure about that. Objective-C (or at the very least C++ =
--=20
something object-oriented) seemed far more suited to the job to me. The=20=

most computationally intensive calculations I can think of in the=20
Shadowrun system can be run on a Casio programable calculator without=20
noticeable lag, so I don't think speed will be a problem in the=20
back-end. Besides, from what I've read ObjC is as fast as C, except=20
that method calls take roughly 1.5* more time.

> Second, portability. This seems kind of obvious. The library would be=20=

> written in C and could be compiled under multiple platforms. We or=20
> other people could then take the library and write an interface (GUI=20=

> or not even) on top of the library to perform tasks in other=20
> environments and other operating systems. This will lend well to an=20
> OSX/Unix/Windows hybrid. The OS X stuff will be able to stay Cocoa and=20=

> will be native, while the other operating system would benefit from=20
> being able to have native support as well. Obviously Windows support=20=

> isn't really a prime focus, but if it becomes an issue this approach=20=

> will make it easy to address. In addition, other platforms such as=20
> Palm and other handhelds could conceivably take advantage of the=20
> library.

	Same as above. Actually, the reason why I'd have liked to use =
ObjC is=20
everything in the NS API that's not GUI-related. There are a number of=20=

classes (NSMutableDictionary, for example -- associative array that can=20=

be grown/shrunk at will) that would be extremely helpful, and GNUStep=20
is available for a lot of platforms.
	I see your point, though, when it comes to handhelds. GNUStep is=20=

unavailable for those, and even if it were the processors in these=20
machines are quite underpowered. But then C++ would be the way to go=20
IMO. I fail see the point in not using an object-oriented language in a=20=

project that screams "OOP" as much as this one does.

> Third, it will aid development of our primary applications. By=20
> breaking away the library we can work on the library code separate=20
> from the GUI code. Thus development of one won't be sacrificed to=20
> development of the other. We can have a bare bones skeleton of the=20
> library in place quickly for the GUI to interface with while it's=20
> developed and the library could use simple text based checks while=20
> it's being worked on. Also, once the code of one part is in place, it=20=

> won't be as reliant on the other.

	Model-View-Controller. Amen to that.

> Fourth, flexibility. By breaking the workhorse code away into a=20
> library it gives us a huge amount of flexibility as to what we want to=20=

> do with the code once our basic goals are met. Some ideas were=20
> presented in the portability section, but conceivably we could do=20
> quite a bit with it, as well as allowing other people to build upon=20
> the library for their own needs, if they want to pursue something we=20=

> don't have the time, resources, or inclination to pursue. Which could=20=

> include a Windows program or any number of things.

	Yup.

> Fifth, expandability. Once the basic library is set, which will=20
> include the basics of handling a character and such we'll be able to=20=

> expand on that. However, we won't have to add it in the same library=20=

> or in the same piece of code. We can avoid unnecessary bloat by adding=20=

> further features into additional libraries. Things such as Cyberdeck=20=

> creation, gun creation, spell creation, vehicle creation, etc. can all=20=

> be added on an as needed basis into any program by keeping things in=20=

> seperate self-contained libraries.

	Good idea.

> It's late, and it's time for me to get some sleep.
>
> Nighto!

	Have a good rest!

-- Max
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting=20
and sweating as you run through my corridors... How can you challenge a=20=

perfect, immortal machine?"