Re: [xsrcg-devel] Program Design Updates

[Adam B. <co...@di...>]

Quoting Max Noel <max...@fr...>:

> 	Sorry if you get this message 2 times, but it seems that Yahoo Mail
> 
> has decided to get a Guinness Book entry for "slowest e-mail
> delivery". 
> I originally sent this this morning and it still hasn't arrived. So,
> 
> here I go again, from a different e-mail account...
> 

Not a problem at all. I'm using my webmail app this time around and it
might not wrap stuff as pretty as Mail.app.

> 
> Le 16 juin 2004, à 08:55, Adam Brown a écrit :
> 
> > Okay, Jesse and I had a pretty long talk this evening on IRC. 
> > Hopefully we can all three get together there soon. Max, you might
> let 
> > us know what time is good for you locally, since you're the odd one
> 
> > out, and hopefully Jesse and I can try and be around at that 
> > time...just a thought.
> 
> 	I'm usually awake from 08:00 to about midnight GMT. I'm not always 
> online during that time, but if you want me to be I'll try.
> 

Well, you don't need to try to be online all the time. Mostly it's just
a "when is it possible to catch Max" question.

> 
> > First, speed. By breaking the guts of the program into a self 
> > contained library we can write it in pure C and do it with a
> minimal 
> > of fuss. This will give the workhorse part of the program a good
> boost 
> > in speed and efficiency.
> 
> 	I'm not sure about that. Objective-C (or at the very least C++ 
> -- something object-oriented) seemed far more suited to the job to
me.
> The 
> most computationally intensive calculations I can think of in the 
> Shadowrun system can be run on a Casio programable calculator without
> 
> noticeable lag, so I don't think speed will be a problem in the 
> back-end. Besides, from what I've read ObjC is as fast as C, except 
> that method calls take roughly 1.5* more time.
> 

Point taken. C vs C++ vs ObjC in this intance probably wouldn't make
much difference speed-wise. Although I think portability of the library
is important, and it's tough to find ObjC compilers on some platforms.



> > Second, portability. This seems kind of obvious. The library would
> be 
> > written in C and could be compiled under multiple platforms. We or
> 
> > other people could then take the library and write an interface
> (GUI 
> > or not even) on top of the library to perform tasks in other 
> > environments and other operating systems. This will lend well to an
> 
> > OSX/Unix/Windows hybrid. The OS X stuff will be able to stay Cocoa
> and 
> > will be native, while the other operating system would benefit from
> 
> > being able to have native support as well. Obviously Windows
> support 
> > isn't really a prime focus, but if it becomes an issue this
> approach 
> > will make it easy to address. In addition, other platforms such as
> 
> > Palm and other handhelds could conceivably take advantage of the 
> > library.
> 
> 	Same as above. Actually, the reason why I'd have liked to use ObjC
> is 
> everything in the NS API that's not GUI-related. There are a number
> of 
> classes (NSMutableDictionary, for example -- associative array that
> can 
> be grown/shrunk at will) that would be extremely helpful, and GNUStep
> 
> is available for a lot of platforms.
> 	I see your point, though, when it comes to handhelds. GNUStep is 
> unavailable for those, and even if it were the processors in these 
> machines are quite underpowered. But then C++ would be the way to go
>

We'll have to look at that. Obviously if we use C or something in the
library the library won't be able to take advantage of some of the ObjC
stuff, but at the same time, the library functions and storage could be
loaded into an ObjC wrapper under Cocoa/GNUStep to give us that
flexibility and power on those platforms. 

I mean, I can see how NSMutableDictionary could be very handy for
storing just about everything short of attributes. So that's a pretty
valid argument. We'll definitely need to look into how having a
non-ObjC library will affect things like that, or if we can work around
them easily enough to keep the library as portable as possible.
 
> IMO. I fail see the point in not using an object-oriented language in
> a 
> project that screams "OOP" as much as this one does.
> 

Very true. Another point we need to look at that I didn't really
address.

I'll leave it at that for now and get back to work...heh.

--
Adam Brown
co...@di...