Final by default?

[Marco Leise]

Am Sat, 15 Mar 2014 21:25:51 +0000
schrieb "Kapps" <opantm2+spam at gmail.com>:

> 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.

What about the way Microsoft went with the Win32 API?
- struct fields are exposed
- layouts may change only by appending fields to them
- they are always passed by pointer
- the actual size is stored in the first data field

I think this is worth a look. Since all these function calls
don't come for free. (Imagine a photo management software
that has to check various properties of 20_000 images.)

-- 
Marco