Re: Defining APIs, best practices.

[steve donovan <steve.j.donovan@...>]

On Mon, Dec 17, 2012 at 6:11 PM, Coda Highland <chighland@gmail.com> wrote:
> I mentioned this two e-mails ago, and doing that adds additional
> overhead to the setter (pairs() and a loop) and further worsens the
> asymmetry between getter and setter.

It depends (once again) whether it happens a million times a second or
not. This style is useful for constructors as well, things which
aren't called that often and operate logically as a single operation.
Consider the common case: setting a property causes an update of the
object, and might even cause a canvas repaint or some other
heavyweight action. By grouping the properties together, we can set
them as a single transaction.

> I don't use Microlight from lack of need of it, but that sounds like a
> great idea. :)

As usual, the hard part is thinking about what the user experience.
Current candidate involves associating each property name with a
table: first value is default (we can deduce type from this if
needed), second and third specifies getter and setter. '_' means just
go through the _NAME field, and 'get' and 'set' mean get_NAME and
set_NAME.  There's a further option to call some general method after
setting _NAME.

Foo:declare_properties {  -- where Foo has been created by class()
   enabled = {true,'get','set'},  -- user must provide set_enabled and
get_enabled methods
   visible = {true,'_','set'},  -- user only provides set_visible,
property value accessed through _visible
   name = {'','_','_','update'}  -- access through _name, with
update() method called after setting _name
  ...
}

We don't _have_ to declare properties - it can all be worked out on
the fly and efficiently cached. But I feel a feature has to be
adequately documentable.

> hail from the Qt community, where we think the C++ community at large
> is a little crazy and we mostly have an implicit agreement that Qt's
> API style is pretty much the best you can do in C++.

Used to be a _big_ fan of C++ but insane over-templatization and
arrogance of the std::community turned me off. Then I discovered
languages which compiled faster ;)

steve d.