Re: Defining APIs, best practices.

[Coda Highland <chighland@...>]

On Sun, Dec 16, 2012 at 11:15 PM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> On Mon, Dec 17, 2012 at 9:08 AM, Coda Highland <chighland@gmail.com> wrote:
>> TL;DR: Don't bash on the "Java"-style properties; they're not bad.
>
> Well, when we have to spell them out as setEnabled() and getEnabled()
> they get pretty tedious.

obj:setEnabled(true)
obj:set("enabled", true)
obj:set{enabled=true}

Of these variations, Java-style is the shortest. :P

> I like property sugar for getters/setters (e.g. as in C#) because you
> may start out exposing a field directly, and end up implementing an
> explicit setter, all without messing with the public API.

obj.enabled = true

Clear winner, and as I said, I like the property approach, for the same reason.

> Also, such properties often fall into families - a whole bunch of them
> basically involve setting some private field and calling update() or
> something like that.

I feel like there's got to be a good way to simplify this no matter
what method you're using. One thing you definitely want to avoid is
big if/elseif/else blocks -- worse, NESTED if/elseif/else blocks.

function defineSimpleProperty(obj, name)
  rawset(obj, "set" .. name:sub(1,1):upper() .. s:sub(2),
function(value) rawset(obj.properties, name, value); obj:update() end)
  rawset(obj, name, function() return rawget(obj.properties, name) end)
 end

I dunno, I'm just speculating -- it hasn't come up for me enough to
warrant bothering.

(Note I shun the "get" prefix, that's just me. You can add it if you like it.)

> But (since self-documenting is never as sufficient as it seems at
> first) you do need to establish a documentation style for properties.

Ayup.

/s/ Adam