[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] GSObjCRuntime API conventions

From: David Ayers
Subject: Re: [RFC] GSObjCRuntime API conventions
Date: Fri, 04 Jun 2004 12:52:35 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514

Kazunobu Kuriyama wrote:

Richard Frith-Macdonald wrote:

On 4 Jun 2004, at 07:07, Kazunobu Kuriyama wrote:

Adam Fedor wrote:

On Jun 3, 2004, at 5:09 AM, David Ayers wrote:

The conventions I'd like to have comments on, is the explicit Class/Instance separation and the explicit Inherited/NotInherited separation as apposed to collapsing those functions into on which takes BOOL flags to determine whether Class vs. Instance or recursive behavior is requested.

I'd rather see a smaller API.

I agree about the smaller API...

Please take the following points into account, too.

First, the smaller API in question definitely requires some
documentation concerning the behavior of the function because it is
supposed to vary depending on the boolean flags. We can skip this
tedious task *for a while* if each function does nothing else other
than one thing described by its name.

This is the obvious difference which I have requested comments for. Thank you.

Secondly, in case we find a bug in such a function and try to fix it,

This point is pretty much irrelevant, as most of these functions are implemented by using each other, which makes many of them rather trivial. I don't believe the maintenance burden is an issue either way. It's more about "many verbose function names" vs. "lean API".

Thirdly, when the function is invoked with explicit boolean values, say

  array = GSObjCGetMethodNames(class, YES, YES);

we wouldn't feel much trouble with it because we do know what the
function is expected to do.  To the contrary, suppose we have
   array = GSObjCGetMethodNames(class, bool_val, another_bool_val);

where bool_val and another_bool_val are given somewhere, and
that a debugger suggests something goes wrong around there.
To fix it, we first have to check the values of bool_val and
another_bool_val to see if intended values are actually passed to
the function.  We could skip this daunting task if the code snippet
above were to be written as

   array = GSObjCGetClassMethodNames(class);

from the outset.

I partially agree with this point, but checking argument values in gdb
is trivial, so I don't think the issue is very important in practice.

Yes, it's trivial.  But think about the total amount of time which might
be spent by people for that.  Also, personally, I don't like to wind
up a lot of stack frames to know where the variables are set when I
can't concentrate on debugging for some reasons (sleepy, exhausted,

Sorry, I don't think that this is very strong argument for defining an API. API should clear an concise wrt to its usage in code, not wrt to debugging. Having the option of using variables or constants should be considered as feature of the API. In the verbose case, you are forced to use 'if' constructs to call the different functions. If you find that this is more readable, there is nothing stopping you from doing the same with the collapsed API using constants instead of variables.

I take down the first point and rely on David in this case.  But I'm
afraid you get me wrong on the second point, as mentioned above.  Also,
I can't buy the third point.  My point is the efficiency of the
maintainance as a whole of the community because I don't think the
capacity of  human's short-term memory should be accounted as a
programming environment.  Considering the huge API of GNUstep, adding
a few functions to it hardly makes difference.

Well this may very well not be the end of it. There are still a few runtime abstractions I've been thinking, of which I simply don't need yet, so I'm holding them back. I asked for comments about the conventions now, before the functions start accumulating.

Adding up the responses, I sense a tendency towards the reduced API. (This means I have to update and retest before I post the final RFC which will contain the patches including documentation.) Unless you (or anyone else) feels strongly that this is the /wrong/ approach, I'd like get that done now so this code can go in before the release, OK?

Thanks to everyone for their feedback!  Highly appreciated.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]