Re: [hackers] [quark] Rewrite quark from the ground up again || Laslo Hunhold

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Fri, 23 Jun 2017 09:08:12 +0200

Hi Laslo,

On 22 June 2017 at 17:29, Laslo Hunhold <dev_AT_frign.de> wrote:
> On Wed, 21 Jun 2017 10:55:20 +0200
> Anselm R Garbe <garbeam_AT_gmail.com> wrote:
>> I really dislike using lowercase enum and struct names. Types should
>> always be easily distinguishable from global / local variable names
>> and shouldn't be required to be qualified with enum or struct in the
>> code (I highly prefer typedef for this eye candy).

[..]
> For a program like quark, which only uses transparent structs for
> internal processing, opaque structs just make no sense, and I think
> typedeffing for the sake of it kind of hurts the readability because it
> takes two steps to jump to the definition instead of one. The extreme

How come? I mean the rationale behind my suggestion of typedef'ing
structs or enums is *not* to make them opaque, but to avoid additional
qualifiers in the code or composed struct definitions which sucks. I
prefer having

Type type;

instead of

struct s_type type;

or within a struct definition:

typedef struct {
  int x;
  Type *types;
} SomeOtherType;

instead of

struct s_some_other_type {
   int x;
   struct s_type *types;
}

It reads much easier avoiding the additional qualifiers.

Wrt. looking up the definition I also don't see the point you are
making if we require the typedef being at the struct definition or
just prior to it due to forward declaration reasons. In order to look
it up, it makes no difference at all.

> case is glibc and Qt, where you have to hoop through multiple layers of
> typedefs and macros to find the definition you were looking for.

But this is not due to the use of typedef's, it's because of the
exposure of opaque types, which I'm not propagating at all.

> I would alter the rule to "Typedef opaque structs", but it depends on
> personal taste and don't mind too much. I know though that many here
> would agree with me based on previous discussions.

NO NO NO -- the coding style is absolutely correct about "_user_
defined types - I never talked about opaque types.

Opaque types relate from the people that learned programming the OO
way first and buy into the argument of information hiding and crap
like that. Elegant libraries and code barley needs information hiding.

Information hiding is particularly required in a OO modelling world,
as there typically mediocre co-developers are your "customers" and you
don't want them to mess in your business logic. But the real problem
is that the typical OO-world mixes data and algorithms together. In C
this barely is a problem. Neither it is with OO done right in Go for
instance.

So I'm really keen on incorporating this style of typedef'ed user
defined types in suckless projects. It has been there for a reason and
it is in dwm/dmenu/ etc. for a reason.

BR,
Anselm
Received on Fri Jun 23 2017 - 09:08:12 CEST