From: "Greg J. Badros" <gjb@cs.washington.edu>
To: Marius Vollmer <mvo@zagadka.ping.de>
Cc: Mikael Djurfeldt <mdj@mdj.nada.kth.se>,
Ariel Rios <ariel@arcavia.com>,
guile@sourceware.cygnus.com, guile-gtk@sourceware.cygnus.com,
djurfeldt@nada.kth.se
Subject: Re: Patch to make guile-gtk work with upcoming guile-1.4
Date: Mon, 19 Jun 2000 15:01:00 -0000 [thread overview]
Message-ID: <qrr66r5uy8z.fsf@clavicle.cs.washington.edu> (raw)
In-Reply-To: <87k8flfjyn.fsf@zagadka.ping.de>
Marius Vollmer <mvo@zagadka.ping.de> writes:
> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
>
> > The `scm_make_smob_type_mfpe' function has not been mentioned in the
> > NEWS file because it might become deprecated in next release of Guile.
>
> But smob.h says:
>
> /* These next two functions are the supported way to create new SMOB types.
>
> scm_make_smob_type is useful if there are no special smob functions
> and the defaults work for mark,free,print,equal_p, or you want to use
> scm_set_smob_{mark,free,print,equalp}, below.
>
> scm_make_smob_type_mfpe is ideal if you need to set one or more of
> the special smob functions-- use NULL for when the default function
> is fine
> */
>
> The comment should be updated, probably.
Or we should just decide not to depracate the _mfpe piece. I think it's
imprudent to require the separate and redundant calls to scm_set_smob_
when the common usage suggests the _mfpe interface that permits
eliminating those redundancies.
Greg
next prev parent reply other threads:[~2000-06-19 15:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-01 21:05 guile-gtk 0.18 Released Ariel Rios
2000-06-18 19:06 ` Patch to make guile-gtk work with upcoming guile-1.4 Greg J. Badros
2000-06-19 2:06 ` Mikael Djurfeldt
2000-06-19 14:11 ` Greg J. Badros
2000-06-19 15:47 ` Mikael Djurfeldt
2000-06-19 14:49 ` Marius Vollmer
2000-06-19 15:01 ` Greg J. Badros [this message]
2000-06-19 21:54 ` Jim Blandy
2000-06-20 8:41 ` Greg J. Badros
2000-06-20 9:15 ` Jost Boekemeier
2000-06-20 9:22 ` Brett Viren
2000-06-19 14:49 ` Marius Vollmer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=qrr66r5uy8z.fsf@clavicle.cs.washington.edu \
--to=gjb@cs.washington.edu \
--cc=ariel@arcavia.com \
--cc=djurfeldt@nada.kth.se \
--cc=guile-gtk@sourceware.cygnus.com \
--cc=guile@sourceware.cygnus.com \
--cc=mdj@mdj.nada.kth.se \
--cc=mvo@zagadka.ping.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).