--- Neil Watkiss <[EMAIL PROTECTED]> wrote:
> Hi Paul,
>
> > Also, how hard would it be to add methods to the struct? For
> > example, after creating an Inline::Struct, creating an Inline::C
> > read() method in that package space? Would it be that easy?
>
> It should be pretty easy. For instance, let's modify my previous
> example:
>
> ----8<----
> use Inline C;
>
> my $o = new Inline::Struct::Foo;
> $o->read;
> $o->Print;
>
> package Inline::Struct::Foo;
> sub read { ... }
> sub Print { ... }
>
> __END__
> __C__
>
> struct Foo {
> int inum;
> double dnum;
> char *str;
> };
> typedef struct Foo Foo;
> ----8<----
Cool. That's one indea I had in mind, and the other was doing the read
in C, straight into the struct. I'd like to see an example for that
also, but that can wait for the Inline::Struct::Cookbook. =o)
> > > FEATURES
> > > o Adds two new configuration options to C and C++:
> > > STRUCTS:
> > > Takes either the name of a struct, or an array ref containing
> > > a list of structs to bind.
> >
> > I assume that if this option is present and a struct is specified
> > which is not in the list, that struct is left unbound.
>
> Correct.
>
> > hmm -- sounds good, but you might want to add another level of
> > abstraction, such as "if it's an array REF, and the number of
> > elements in the referenced array match the number of fields in the
> > struct...."
> >
> > That limits the flexibility it has now, but would circumvent the
> > following problem --
> >
> > > -- elsif the number of args is divisible by 2, assume
> > > it's a "hash" assignment: new Foo(str => 'neil', inum => 10).
> > > Any unassigned items remain zero'd.
> >
> > This is great, but what if there is an even number of elements in
> > the array, and you want to assign to exactly half of them? This
> > setup will read that the args passed match the number of elements
> > in the struct, and the previous step will catch it before it gets
> > here (which may be disastrous, depending on how you handled the
> > type conversions...)
> >
> > If the above requires an aray ref, you can't have that problem. You
> > might want to require or allow a hash ref here as well just for
> > consistency, or whatever, but watch for this as a possible bug.
> > Yes?
>
> Damn! I hadn't thought of that. You're probably right -- maybe I'll
> use an array ref. On the other hand, why not a hash ref? I'll think
> about it more.
Either is good. If you use one, though, I'd make it possible to use the
other. More work, but more flexibility as well, and more importantly,
more consistancy.
I only suggested that you make the array the required ref because I
think it's likely folk will want to pre-initialize just a few things
more often that every item in the object. Obviously it depends on the
object and its use, but you said the default was a null'd struct. If
you only initialize four elements, the rest are still zeroed, right?
> > > -- else croak.
> >
> > Croaking is probably best, but you might consider checking to see
> > if there's exactly one arg and it is in fact another instance of
> > the same struct type, in which case you could clone it. I wouldn't,
> > but I just thought I'd toss out the thought in case it sounded good
> > to you (lol....)
>
> Well, that might be useful... I'm not sure though. Then I'd have to
> do a deep copy, and that's something I don't want to bother with.
Like I said, I wouldn't do it. I was just presenting the idea, just in
case. =o)
> > > DESTROY -- frees the C structure, iff it was allocated by Perl.
> >
> > I presume that "iff" is an "if-and-only-if"?
>
> Yes.
>
> > > _HASH -- returns a hash ref containing the field/value pairs.
> > > _ARRAY -- returns an array ref containing the field values.
> > > Struct order.
> > > _KEYS -- returns an array ref containing the field names.
> > > Struct order.
> > > In addition, each field generates a method of the same name. If
> > > you pass it no arguments, it returns the value of that field.
> > > If you pass it an argument, it sets that field and returns the
> > > object, so that you can chain such assignments:
> > > $o->inum(10)->dnum(3.1415);
> >
> > That's very cool. Odd (to me at least), but *very* cool.
> > Quick question -- what if one element of a struct is a pointer to
> > another struct of a bound type? Could you say
> >
> > $struct1->struct2()->subelement(); # ???
>
> Absolutely! Currently there's a caveat: you can't have a recursive
> structure. That is, you can't have a linked-list struct, because I
> only bind to things which are in the typemap, and the struct isn't
> added to the typemap until after it has been defined. So this:
>
> struct Node {
> struct Data *data;
> struct Node *next;
> };
>
> would not be bound to Perl, because 'struct Node' has not been
> defined at the point where 'next' is defined. Changing the grammar
> should be possible, but it's low priority IMHO.
If somebody *really* needs to use it for linked lists, they can declare
it as a void pointer and then write an $obj->next() method that
typecasts it back. ;o]
> > > - typemaps: For each struct, it generates a typemap so that you
> > > can pass struct objects back into Perl from C functions, or
> > > vice versa.
> > > - convenience macros:
> > > INLINE_STRUCT_NEW(target, type) -- allocate a new <type>
> > > INLINE_STRUCT_FIELDS(type) -- returns #fields in <type>
> > > INLINE_STRUCT_INIT_LIST(target, type) -- inits target from
ST()
> >
> > ST()?
>
> The Stack. Sorry.
lol -- no prob.
> Thanks for your suggestions,
> Neil
You're very welcome! Hey, I'm looking forward to using this.
Keep up the good work.
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/?.refer=text
