Re: [xsrcg-devel] Program Design Updates

[Jesse W. <jwa...@sp...>]

/* Thus spake Adam Brown (co...@di...) on  0 */

> 
> 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.
> 

of course.  using C would be more a matter of portablility than of
speed.  though, speed could certainly influence certain levels of
portability.  more on this below.
 
> 
> > > 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
> >
> 
Max, yes i had the same ideas about ObjC.  i love the non-gui lib 
that's in there.  all the NS stuff.  it's good stuff.  we even talked
about using objective C for the back lib.  but again, much of it is a
matter of portability.  if we *did* decide to use C, i would at least 
want to use glib or something.  glib, and others, provide some
great functions and defs.  i.e. linked lists, mutable strings,
mutable lists, hashing.  it's something we need to consider.  not
just because C would be more difficult, but because of what other
langs offer.  which happens to be really good standard libs that
contain stuff that we wouldn't want to recode.  i will say that
even C++ can get ugly accross platforms and stdlib implementations.

> 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.

OOP is great, i agree.  the main things we would be taking advantage
of in this project are polymorphism and inheritance.  stuff like gear
with mostly the same attributes and stuff like the different
generation systems would be tougher in C...of course there we would
use a procedural approach instead of trying to force it into an
Object-Oriented model.  but, still, OOP would be much more
programmer-friendly for this project.  however, as we've
discussed--objc wouldn't be as portable.  So, we may need to be
discussing our scope and goals before what language we need to use.
exactly how portable do we want this lib to be?  perhaps the answer
truly is a middle-ground between portability and programmability.  in
that case, the best middle-ground candidate just may be C++ (without
a lot of fanciness).  i dunno.  but right here and right now, i'm not
an advocate for anything but this project =).  so don't think that
i'm pushing anything.  i'm up for whatever.  if we *do* decide to use
straight C, then i would definitely want to investigate glib's
portability.  let me link you guy's to info about glib so you know
what i mean: 
http://www.gtk.org/tutorial/ch-glib.html
http://developer.gnome.org/doc/API/glib/
i'm not saying we'd have to use glib, but a similar library would be
very nice if we code in straight C.

Max, i'm not sure if adam mentioned libxml2 or not.  i was playing
with it last night, and it's quite nice.  we could use that for xml
handling in any language that we decide to write the lib.

gotta go.  take care.

-jesse
jwa...@sp...

> 
> --
> Adam Brown
> co...@di...
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> xsrcg-devel mailing list
> xsr...@li...
> https://lists.sourceforge.net/lists/listinfo/xsrcg-devel
> 
> 
/* End of Adam Brown's message */