Re: [dev] Conversation with Anselm R. Garbe of suckless.org

2009/9/15 frederic <fdubois76_AT_gmail.com>:
> I believe that closures could improve dwm for instance. Anselm says that
> he doesn't miss them, but it seems to me that he used a lot of tricks to
> replace
> them.
> For instance, the Monitor struct packs all of the fields that a layout
> function may need.
> The Arg union allow to pass an argument to various functions that needs
> various types of
> constant parameters. Maybe in the next evolution, where the symbol of the
> layout will be given by
> a function pointer, one may expect some similar tricks.
> This is typically what one has to do without closures. One may accommodate
> this in such
> a small program, after all - but one has already bypassed the type checker
> (union) and paid
> a few bytes for this (kitchen sink structure) in a little 2K SLOC program.
> I'm not sure one can live with
> it in 10 KSLOC programs (or making it bearable helps in reaching faster the
> 10KSLOC).
>
> Anonymous functions alone - not even full-blown closures - could replace
> the function pointer/argument pair in the Key structure. With closures, one
> can
> create layout functions that carry with them their own data. No need to put
> everything in
> one big Monitor structure.
>
> I'm pretty sure that if C featured closures, Anselm would cleverly use them
> and
> make an even more simple, customizable and elegant dwm.

There are some areas in dwm that might benefit from anonymous
functions, I'm not too convinced about imagining dwm's Monitor struct
as a closure, because I see it as a big advantage to have easy and
clear access to the dwm data structs from everywhere. Once you
introduce closures you end up opening up holes into them in order to
access hidden data structs sooner or later.

Another thing I pretty much dislike in OO is the inflationary use of
'pointless' hiding of private or protected fields that are in 90% of
all cases I came across exposed using public getters and setters --
this is particularly true for Java. If these getters or setters would
be implementing an interface or perform setter checks I might be able
to understand. But most Java pseudo-closure holes look like this:

class X {
  private int foo;

  public void setFoo(int foo) {
      this.foo = foo;
  }

  public int getFoo() {
      return this.foo;
  }
}

IDE's like Eclipse have code assitance support to generate these
automatically, great isn't it? So if you imagine a Java program where
each datum access happens through getters and setters, the program
must become a magnitude faster if the underlying code would be
replaced using direct datum/field access instead, wouldn't it?

Kind regards,
Anselm
Received on Wed Sep 16 2009 - 07:42:10 UTC