Re: [textadept] Boolean Arguments

From: mitchell <c....at.caladbolg.net>
Date: Mon, 19 Dec 2011 12:01:27 -0500 (Eastern Standard Time)

Robert,

On Sun, 18 Dec 2011, Robert wrote:

> Hi Mitchell,
>
> there are quite a few cases in TA's API where some of the arguments
> are boolean. If the function is not used very often this typically
> requires looking up its meaning.
> For a discussion of some real-world JavaScript API examples and
> problems with boolean arguments see here:
> http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html

I agree with a number of points in the article, but there are a lot of
things I don't like when using non-boolean arguments:

> One possibility would be to use tables as arguments, for example like
>
> goto_view{1, relative = true} -- mixed named and positional arguments
> or
> goto_view{n = 1, relative = true}

I don't like the idea of having to create tables and look up arguments in
them. Not only is creating temporary tables wasteful, but mistyping
argument keys is annoying and I am guaranteed to have to look-up what keys
I want to use.

> Another option, a wrapper function
> goto_view_relative(-1)

This won't be done at the C level because that will inflate the LOC count
needlessly. At the Lua level, an event needs to be connected to a
VIEW_NEW, the appropriate functions created, and then the usual 'if not
RESETTING then ... end' outside the event connect function. I don't feel
like I use view:goto_buffer() and gui.goto_view() enough outside of the
few calls in my keys.lua to justify adding these functions.

> It is of course easy to look up the arguments because there is API
> documentation available, still I think it would be better to have
> something like
> view:split("vertical")
> or view:split_horizontal() and view:split_vertical()
> than
> view:split(true).

See the most recent paragraph. Also,

_m.textadept.editing.current_word() uses a string argument and it feels
really ugly. Not only can I easily mistype it, but I have to look in the
documentation for any more strings that I can pass for a different effect
(there are none). Thus I'd prefer to use a boolean, but it's even worse
than view:split(true/false) since true would delete the current word as
opposed to selecting it.

> Possibly named functions are best, because they can be quickly used
> through auto-completion.

I agree with this, but increasing the LOC count does not seem worth it. I
will think on this more though.

mitchell
Received on Mon 19 Dec 2011 - 12:01:27 EST

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 12:26:38 EST