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.

Cough getopt.

Am Sat, 15 Mar 2014 21:25:51 +0000
schrieb "Kapps" <opantm2+spam@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

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

It comes for free if you enforce inlining and recompile for major revisions of libs.

On 3/15/2014 11:33 AM, Michel Fortin wrote:
> And it also breaks binary compatibility.

Inlining also breaks binary compatibility. If you want optimizations, and be able to change things, you've got to give up binary compatibility. If you want maximum flexibility, such as changing classes completely, use interfaces with virtual dispatch.

Maximum flexibility, maximum optimization, and binary compatibility, all while not putting any thought into the API design, isn't going to happen no matter what the defaults are.

On 15 Mar 2014 13:45, "Johannes Pfau" <nospam@example.com> wrote:
>
> Am Fri, 14 Mar 2014 19:29:27 +0100
> schrieb Paulo Pinto <pjmlp@progtools.org>:
>
> > That is why the best approach is to have one module per platform specific code, with a common interface defined in .di file.
>
> Which is basically what Iain proposed for druntime. Then the thread got hijacked and talked about three different issues in the end. Walter answered to the other issues, but not to Iain's original request, Andrei agreed with Walter, the discussion ended, pull request closed and nothing will happen ;-)
>
>
> https://github.com/D-Programming-Language/druntime/pull/731 https://github.com/D-Programming-Language/druntime/pull/732
>
> I think we'll have to revisit this at some point, but right now there's other stuff to be done...

Indeed other stuff needs to be done, it just so happens that thanks to sys.posix's bad design splitting out other modules into ports will be more a pain.  But it shows how *no one* in that thread who responded either against the first pull, or went off and hijacked the second had a Scooby about the issue being addressed.  Didn't even have the curiosity to give alternate suggestions.

On 2014-03-16 00:11, Marco Leise wrote:

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

The modern runtime for Objective-C has a non-fragile ABI for its classes. Instead of accessing a field with an compile time known offset an offset calculated at runtime/load time is used when accessing a field. This allows to freely reorganize fields without breaking subclasses.

-- 
/Jacob Carlborg

On 14.03.2014 23:25, deadalnix wrote:
> On Friday, 14 March 2014 at 22:06:13 UTC, Daniel Kozák wrote:
>> First I think have something like
>>
>> @disable(final,nothrow) would be the best way, but than I think about it
>> and realize that final(false) is much more better.
>>
>
> If I may, final!false . We have a syntax for compile time
> parameter. Let's be consistent for once.
>
> The concept is solid and is the way to go. DIP anyone ?

To me, it's not a decision "final or virtual", but "final, virtual or override", so a boolean doesn't work. final!false could infer "virtual or override", but then it would loose the explicitness of introducing or overriding virtual.

I'm in favor of adding the keyword "virtual", it is known by many from other languages with the identical meaning. Using anything else feels like having to invent something different because of being opposed to it at the start.

Adding compile time evaluation of function attributes is still worth considering, but I'd like a more generic approach, perhaps something along a mixin functionality:

enum WINAPI = "export extern(Windows)";

@functionAttributes!WINAPI HANDLE GetCurrentProcess();

though I would prefer avoiding string mixins, maybe by providing a function type as prototype:

alias export extern(Windows) void function() fnWINAPI;

@functionAttributesOf!fnWINAPI HANDLE GetCurrentProcess();

On Saturday, 15 March 2014 at 22:50:27 UTC, deadalnix wrote:
> On Saturday, 15 March 2014 at 20:15:16 UTC, Araq wrote:
>>> However, this is clear that it come at a cost. I don't doubt an OO language pushing this to the extreme would see concept that confuse everybody emerging, pretty much like monads confuse the hell out of everybody in functional languages.
>>
>> Looks like explicit continuation passing style to me. So "OO done right" means "Human compiler at work"...
>
> Sound like you are enjoying criticize OOP, but so far, you didn't come up with anything interesting. Please bring something to the table or cut the noise.

I note that you are not able to counter my argument and so you escape to the meta level. But don't worry, I won't reply anymore.

On 16 March 2014 21:28, Rainer Schuetze <r.sagitario@gmx.de> wrote:

>
>
> On 14.03.2014 23:25, deadalnix wrote:
>
>> On Friday, 14 March 2014 at 22:06:13 UTC, Daniel Kozák wrote:
>>
>>> First I think have something like
>>>
>>> @disable(final,nothrow) would be the best way, but than I think about it
>>> and realize that final(false) is much more better.
>>>
>>>
>> If I may, final!false . We have a syntax for compile time parameter. Let's be consistent for once.
>>
>> The concept is solid and is the way to go. DIP anyone ?
>>
>
> To me, it's not a decision "final or virtual", but "final, virtual or override", so a boolean doesn't work. final!false could infer "virtual or override", but then it would loose the explicitness of introducing or overriding virtual.
>
> I'm in favor of adding the keyword "virtual", it is known by many from other languages with the identical meaning. Using anything else feels like having to invent something different because of being opposed to it at the start.
>
> Adding compile time evaluation of function attributes is still worth considering, but I'd like a more generic approach, perhaps something along a mixin functionality:
>
> enum WINAPI = "export extern(Windows)";
>
> @functionAttributes!WINAPI HANDLE GetCurrentProcess();
>
> though I would prefer avoiding string mixins, maybe by providing a function type as prototype:
>
> alias export extern(Windows) void function() fnWINAPI;
>
> @functionAttributesOf!fnWINAPI HANDLE GetCurrentProcess();
>

I frequently find myself needing something like this. What's wrong with
aliasing attributes directly?
DGC/LDC offer their own internal attributes, but you can't make use of them
and remain portable without an ability to do something like the #define
hack in C.

On Sunday, 16 March 2014 at 13:23:33 UTC, Araq wrote:
> I note that you are not able to counter my argument and so you escape to the meta level. But don't worry, I won't reply anymore.

Discussing OO without a context is kind of pointless since there is multiple schools in the OO arena. The two main ones being:

1. The original OO analysis & design set forth by the people behind Simula67. Which basically is about representing abstractions (subsets) of the real word in the computer.

2. The ADT approach which you find in C++ std libraries & co.

These two perspectives are largely orthogonal…

That said, I think it to be odd to not use the term "virtual" since it has a long history (Simula has the "virtual" keyword). It would look like a case of being different for the sake of being different.

Then again, I don't really mind virtual by default if whole program optimization is still a future goal for D.

Ola.