Use of complete GList functionality? Change to GSList?

[Derek Atkins]

That's nice for the scheme side, but doesn't help when coding in C.
:)

At least in many cases it's easy to determine (either from member
names or a quick code inspection) the data type of a list.
Unfortunately this isn't true everywhere in the code. :(

-derek

grib@gnumatic.com (Bill Gribble) writes:

> On Sun, Mar 04, 2001 at 08:58:07PM -0500, Derek Atkins wrote:
> > One of my major issues with the GList construct is that there is no
> > way to validate the _type_ of list you've got.  In other words, there
> > is no way to be assured that you have list of type foo.  I could pass
> > a GList of type foo to a function that is expecting a GList of type
> > bar, and there is no way to detect that.  :(
> 
> Well, RLB has addressed this problem with g-wrap by making it a
> design-time problem.  You can specify in the g-wrap def file that a 
> GList has a certain type of pointer in ->data... in fact, you are required
> to do so... and it's a design "contract" on the C side that you must
> build glists with that type.  
> 
> It's not compile-time type checking, or even run-time type checking,
> which would be required for it really to be a contract, but there is
> at least a handshake agreement that functions that return GLists
> return GLists pointing to a certain type of data, and that that type
> is documented in the g-wrap interface def file if nowhere else.
> 
> b.g.
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available