From: Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>
Cc: guile-devel@gnu.org
Subject: Re: GH replacement proposal (includes a bit of Unicode)
Date: Wed, 26 May 2004 23:27:04 +0200 [thread overview]
Message-ID: <40B50BA8.2050604@dirk-herrmanns-seiten.de> (raw)
In-Reply-To: <87isel64mf.fsf@zagadka.ping.de>
Marius Vollmer wrote:
> Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
>
> > Marius Vollmer wrote:
> >
> >> Hmm, yes, that might make sense. However, the -1 idiom is pretty
> >> much standard for this kind of interface, no?
> >
> > I personally don't like this kind of 'one value, several meanings'
> > paradigm:
> >
> > - What, if instead of -1, you pass -2? [...] - Readability suffers.
> > [...]
>
> Yes, I agree that the -1 idiom is not self explaining, but it is well
> established and people will instantly recognize it. I'd even argue
>
What about the -2 and so on?
You are trying to explain why the -1 idiom is not too bad. But, why
do you think it is better? Do you want to save an identifier? This
can't really be the reason. Especially when looking at Paul's suggestion
to introduce a macro scm_from_locale_0string, which also introduces
a new identifier (and, Paul, I like your name better than my suggestion).
> established and people will instantly recognize it. I'd even argue
> that they will expect to be able to pass -1 for a 'len' parameter and
> will be annoyed when they find out that Guile doesn't allow it.
That's a guess. Maybe you should ask the people what they would prefer?
Considering me as part of them, I would not prefer having the -1 idiom.
> > SCM s = scm_from_locale_memory (str, len);
>
> This can be had with scm_from_locale_string as well, of course. When
> you write
>
> SCM s = scm_from_locale_string (str, len);
>
> thats just as readable, I'd say.
I agree that the function name scm_from_local_string when called with
arguments str and len is not less readable (even better, I would say) than
scm_from_locale_memory when called with arguments str and len. My point,
however, was rather in the direction of saying that if the len argument is
required since the application really knows the length, then passing it will
always be readable. This is in contrast to passing the magic number -1
if the
application does not know the length.
However, I think you oversimplify my concerns if you only boild it down to
the readability issue. There is also the aspect of type checking support
by the
compiler, the fact that code that works mostly with 0strings always has to
pass an unnecessary parameter, the fact that the scm_from_locale_string
function always has to handle the special -1 case, and probably more.
Summarized, I would just claim that it is not a good API design, since I
have
not yet seen a convincing argument in favor of it.
Considering your and Paul's answer, I would like to change my suggestion
to the following pair of functions:
SCM scm_from_locale_string (const unsigned char *str, size_t len);
SCM scm_from_locale_0string (const unsigned char *str);
Best regards,
Dirk
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2004-05-26 21:27 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-07 13:00 GH replacement proposal (includes a bit of Unicode) Marius Vollmer
2004-04-07 15:04 ` Paul Jarc
2004-04-13 13:25 ` Marius Vollmer
2004-04-13 15:54 ` Paul Jarc
2004-04-21 15:08 ` Marius Vollmer
2004-04-21 16:10 ` Paul Jarc
2004-04-21 18:06 ` Marius Vollmer
2004-04-21 16:31 ` Delivery failure (guile-devel@gnu.org) Bruce Korb
2004-04-21 21:34 ` GH replacement proposal (includes a bit of Unicode) Marius Vollmer
2004-04-21 21:46 ` Paul Jarc
2004-04-21 22:19 ` Dale P. Smith
2004-04-21 22:34 ` Paul Jarc
2004-04-21 23:02 ` Kevin Ryde
2004-04-22 17:36 ` Dirk Herrmann
2004-04-22 18:31 ` Paul Jarc
2004-05-17 21:14 ` Marius Vollmer
2004-05-17 21:57 ` Bruce Korb
2004-05-18 9:54 ` Marius Vollmer
2004-04-22 17:00 ` Dirk Herrmann
2004-04-24 10:06 ` Dirk Herrmann
2004-04-24 19:46 ` Marius Vollmer
2004-04-25 20:33 ` Dirk Herrmann
2004-04-25 21:38 ` Paul Jarc
2004-05-17 21:45 ` Marius Vollmer
2004-04-17 13:21 ` Dirk Herrmann
2004-04-22 4:16 ` Rob Browning
2004-04-22 17:48 ` Dirk Herrmann
2004-05-12 20:09 ` Marius Vollmer
2004-05-15 9:50 ` Dirk Herrmann
2004-05-24 18:51 ` Marius Vollmer
2004-05-25 0:21 ` Paul Jarc
2004-05-26 21:27 ` Dirk Herrmann [this message]
2004-06-03 21:40 ` Marius Vollmer
2004-06-04 6:52 ` tomas
2004-08-09 22:29 ` Marius Vollmer
2004-05-15 10:18 ` Dirk Herrmann
2004-05-24 19:36 ` Marius Vollmer
2004-05-26 22:11 ` Dirk Herrmann
2004-08-09 22:28 ` Marius Vollmer
2004-04-22 4:39 ` Rob Browning
2004-04-22 17:58 ` Dirk Herrmann
2004-04-23 0:25 ` Rob Browning
2004-04-23 16:57 ` Marius Vollmer
2004-04-23 17:16 ` Rob Browning
2004-05-17 21:24 ` Marius Vollmer
2004-04-23 17:36 ` Andreas Rottmann
2004-05-17 21:30 ` Marius Vollmer
2004-05-18 9:21 ` Andreas Rottmann
2004-04-25 7:54 ` Dirk Herrmann
2004-05-17 21:44 ` 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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40B50BA8.2050604@dirk-herrmanns-seiten.de \
--to=dirk@dirk-herrmanns-seiten.de \
--cc=guile-devel@gnu.org \
/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).