On 24-May-00 at 18:50, Jeffrey W. Baker ([EMAIL PROTECTED]) wrote:
> On Wed, 24 May 2000, Peter Haworth wrote:
> > Jeffrey W. Baker wrote:
> > > On Wed, 24 May 2000, Peter Haworth wrote:
> > > > Jeffrey W. Baker wrote:
> > > > > myInput = hfTextInputNew();
> > > > > myInput->addAttr(myInput, "name", "first_name");
> > > > > myInput->addAttr(myInput, "value", "Jeffrey");
> > > > > printf("%s\n", myInput->render(myInput));
> > > > > myInput->destroy(myInput);
> >
> > Is this C or C++? If C, do you have a member for each function in the
> > struct, and if it's C++, why are you passing myInput twice? Or maybe you
> > just got carried away with your example.
>
> It's C with function pointers as struct members.
That seems a little excessive to me spacewise, but I guess it means you can
keep the functions static, and not confuse users with differently named
functions to do the same thing with different types of input.
> > > Actually, there is another way, and that is to simply build a linked
> > > list of attributes. It doesn't matter what order you put the
> > > attributes in, so I just add them to the head of the list for
> > > performance. Adding to the head of a list is faster than hashing
> > > anyway. If you use the setAttr(self *, char *, char *) method, the list
> > > has to be scanned, but is is likely to be so short as to not matter.
> >
> > OK, that seems sensible. There's no reason to go overboard to get more
> > hash-like semantics, when you'll generally just be stuffing things in,
> > then reading them all out.
>
> Exactly. The mainstream use case is to add things and then render. The
> capability to remove and change things exists, but doesn't need to be as
> streamlined.
>
> > > The other advantage here is storage space. An attribute in this
> > > implementation takes up only 4*sizeof(void *) + strlen(name) +
> > > strlen(value) + 2.
> >
> > Is it a doubly linked list, or are you storing something other than name,
> > value, next?
>
> Doubly-linked. You aren't sweating those extra 32 bits are you? ;)
It's just that you said you were adding at the list head for performance. I
can't see the need for a doubly linked list if you don't have a pointer to the
tail.
> > Well, personally, I'd have sorted my options before setting them up.
> > Otherwise you need unnecessarily complicated comparison functions to
> > keep your "Please select something" option at the top. ALthough, if it
> > works that way, adding options to a select has to add to the tail of the
> > list, or you'd have to add your options in reverse order.
>
> If the options are sorted before adding, then you just wouldn't call the
> sort() method. Or maybe it would be sortByValue() and
> sortByLabel(). That sounds more flexible.
Not sorting still gets my vote. There are too any cases where you can't sort on
just the value or just the label.
Anyway, I'd still like to see the code. In the meantime, HTML::StickyForm will
probably start off in pure perl. The internals can always be rewritten to use
your library at some point in the future.
--
Peter Haworth [EMAIL PROTECTED]
The world is coming to an end. Please log off.
