On Saturday, 15 March 2014 at 18:18:28 UTC, Walter Bright wrote:
On 3/15/2014 2:21 AM, Paulo Pinto wrote:
In any language with properties, accessors also allow for:
- lazy initialization
- changing the underlying data representation without
requiring client code to
be rewritten
- implement access optimizations if the data is too costly to
keep around
You can always add a property function later without changing
user code.
In many situations you can't. As was already mentioned, ++ and
taking the address of it were two such situations.
ABI compatibility is also a large problem (less so in D for now,
but it will be in the future). Structs change, positions change,
data types change. If users use your struct directly, accessing
its fields, then once you make even a minor change, their code
will break in unpredictable ways. This was a huge annoyance for
me when trying to deal with libjpeg. There are multiple versions
and these versions have a different layout for the struct. If the
wrong library is linked, the layout is different. Since it's a D
binding to a C file, you can't just use the C header which you
know to be up to date on your system, instead you have to make
your own binding and hope for the best. They tr
y to work around this by making you pass in a version string when
creating the libjpeg structs and failing if this string does not
exactly match what the loaded version. This creates a further
mess. It's a large problem, and there's talk of trying to
eventually deprecate public field access in libjpeg in favour of
accessors like libpng has done (though libpng still uses the
annoying passing in version since they did not use accessors from
the start and some fields remained public). Accessors are
absolutely required if you intend to make a public library and
exposed fields should be avoided completely.
