On 6/7/2013 8:59 PM, Manu wrote:
> Because they embody functionality, not just data. That's just how many many
> programmers write code.
> Go to university for a couple of years, see what they tell you... ;)
> Some of these systems can effectively be considered plugins. Consider
> OpenGL/DirectX? DirectSound/XAudio? Linux has a million back-end API's to choose
> from.
> I can see why many people feel it's natural to design their API's/systems that
> way, right or wrong.


So they don't need to be classes at all. It's not about embodying functionality vs data. It's about having a value type vs a polymorphic ref type.

On 06/08/2013 06:39 PM, Walter Bright wrote:
> So they don't need to be classes at all. It's not about embodying functionality vs data. It's about having a value type vs a polymorphic ref type.

I've had quite good experiences using template mixins to generate struct polymorphism (in practice it's more of a policy class way of operating).  The main problem is that this tends to slow down compilation quite a bit, though less so with DMD than with the other 2 compilers.

On 06/08/2013 12:43 AM, Walter Bright wrote:
> On 6/7/2013 2:52 AM, Timon Gehr wrote:
>> You are certainly wrong about the value range propagation part. The
>> transformers
>> for the bitwise operators are not the best possible.
>>
>> ubyte x = ((y&252)^2)+1;
>>
>> The above term can be easily proven to fit into ubyte by just using an
>> analysis
>> of the ranges of its subterms, yet DMD rejects it.
>
> Since it's easy, I expect a pull request from you,

Well,

1. DMD is written in C++.
2. My last pull request has rotten for 6 months now.

> or at least a bugzilla entry with a description of the algorithm to use!

http://d.puremagic.com/issues/show_bug.cgi?id=10310

On 6/8/2013 4:35 PM, Timon Gehr wrote:
> 2. My last pull request has rotten for 6 months now.

Sorry about that.

On 9 June 2013 02:39, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/7/2013 8:59 PM, Manu wrote:
>
>> Because they embody functionality, not just data. That's just how many
>> many
>> programmers write code.
>> Go to university for a couple of years, see what they tell you... ;)
>> Some of these systems can effectively be considered plugins. Consider
>> OpenGL/DirectX? DirectSound/XAudio? Linux has a million back-end API's to
>> choose
>> from.
>> I can see why many people feel it's natural to design their API's/systems
>> that
>> way, right or wrong.
>>
>
>
> So they don't need to be classes at all. It's not about embodying functionality vs data. It's about having a value type vs a polymorphic ref type.
>

Hey? I'm not sure what you're saying..
I just said that people do use classes. And that implies a ref type with
some amount of polymorphism.
These API's are reference based, and there is always a few virtuals. And
these are just trivial examples, a large game unifies a lot of code from
basically all fields of computing.
Trust me, I wouldn't bother spending all this time making a noise about the
performance characteristics of classes if we didn't want/use classes.

On 8 June 2013 21:27, Flamaros <flamaros.xavier@gmail.com> wrote:

> On Saturday, 8 June 2013 at 03:59:25 UTC, Manu wrote:
>
>> On 8 June 2013 13:25, Walter Bright <newshound2@digitalmars.com> wrote:
>>
>>  On 6/7/2013 5:15 PM, Manu wrote:
>>>
>>>  I can tell you that in my case, we export a lot(/most) things. Renderer
>>>> api,
>>>> sound api, etc are often all in their own libraries. So none of them are
>>>> ever
>>>> eligible for optimisation.
>>>>
>>>>
>>> I'm curious why these exports all must be classes, and cannot be structs?
>>>
>>>
>> Because they embody functionality, not just data. That's just how many
>> many
>> programmers write code.
>> Go to university for a couple of years, see what they tell you... ;)
>> Some of these systems can effectively be considered plugins. Consider
>> OpenGL/DirectX? DirectSound/XAudio? Linux has a million back-end API's to
>> choose from.
>> I can see why many people feel it's natural to design their API's/systems
>> that way, right or wrong.
>>
>> I don't agree with it personally, I would write it differently, but I'll
>> never win that argument. Tech/systems programmers are vastly outnumbered
>> in
>> most studios. And of course, most programmers are junior-mid experience,
>> that's just commercial reality.
>>
>
> Personally, I never understood why portability must pass by a plugin
> architecture. In our game engine we use macro to build the right
> implementation depending on the target platform and pure interfaces to be
> sure that API are respected.
> It's not an issue, because the user don't have to be able to choose the
> sound backend, and developer can do it for testing but it requires a full
> rebuild (a real issue due to the C++ slow compilation).
>

But you are aware that people write code that way?
I'm trying to represent the interests of an industry, not just myself.
Anyone who rejects D because they perceive it doesn't meet their needs is a
lost opportunity.

Here's some example game-dev type API's.
http://www.ogre3d.org/docs/api/html/namespaceOgre.html
http://www.continuousphysics.com/Bullet/BulletFull/annotated.html
These aren't particularly aggressive libs, but they are public, so you can
see the sort of API that's typical as an example. Count the occurrences of
'virtual'...
Note, the accessors almost never declare virtual, unless they are
low-frequency classes, like 'Compositor', which is mostly virtual (gets hit
once per frame).

The ones I'm most familiar with are naturally closed-source or proprietary. For instance, Havok, FMod, Morpheme, Unreal, etc... All C++, with careful application of 'virtual'.

Microsoft API's (DirectX, etc) are COM, which implies classes.

People use classes. Classes are not optional. I'm not looking for
workarounds or alternative solutions.
If we can't supply classes that people can use in more-or-less the same way
they have been doing so for decades, they probably won't choose D.

If D does offer some superior alternative paradigms, given time, they might
experiment and become comfortable with them eventually (prove to themselves
it's solid and satisfies all their requirements). But they won't just take
your word for it, and certainly not without a wealth of other successful
examples in the industry.
Programmers that make the switch to D have already taken on enough risk in
that first step alone. If they have to risk changing a decade of coding
habits and conventions too (which involves retraining all the staff), how
can any business ever realistically make the change?

I'm here, and interested in D due mainly to it's immediate familiarity, as
opposed to others like Rust for instance. I can actually envision a
migration. It seems like it's possible... one step at a time.
...it's also compiled and binary compatible, which is obviously critical ;)
.. (this is where C# fails, or everyone would already be on that wagon
without question)

On 06/09/2013 04:57 AM, Walter Bright wrote:
> On 6/8/2013 4:35 PM, Timon Gehr wrote:
>> 2. My last pull request has rotten for 6 months now.
>
> Sorry about that.

No problem. Thanks for merging!

On 6/9/13 6:58 AM, Timon Gehr wrote:
> On 06/09/2013 04:57 AM, Walter Bright wrote:
>> On 6/8/2013 4:35 PM, Timon Gehr wrote:
>>> 2. My last pull request has rotten for 6 months now.
>>
>> Sorry about that.
>
> No problem. Thanks for merging!

FWIW I look forward to https://github.com/D-Programming-Language/dmd/pull/1839 being pulled. I've recently done some manual work of removing unnecessary dependencies, and it's very tedious. Any help would be great. For example, I'd love it if the compiler with -deps generated info such as:

importUseCount modulename count

meaning the imported modulename was used inside the current module count times. A simple script can grep for instances of count=0 so that users know what imports can be safely removed. A low use count such as 1-2 suggests it's possible to push that import down to places using it. One more important use case is:

importUseCountInUnittests modulename count

which only counts use inside unittests. Modules that are only used while unittesting should not be imported for normal use.


Andrei

On 6/9/13 6:58 AM, Timon Gehr wrote:
> On 06/09/2013 04:57 AM, Walter Bright wrote:
>> On 6/8/2013 4:35 PM, Timon Gehr wrote:
>>> 2. My last pull request has rotten for 6 months now.
>>
>> Sorry about that.
>
> No problem. Thanks for merging!

Speaking of imports and dependencies, there was a dependency graph for Phobos that was circulating at some point. It used a script in conjunction with a graph printing program (such as dot or viz). Where is it?

Thanks,

Andrei

On Sun, 09 Jun 2013 16:19:32 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 6/9/13 6:58 AM, Timon Gehr wrote:
>> On 06/09/2013 04:57 AM, Walter Bright wrote:
>>> On 6/8/2013 4:35 PM, Timon Gehr wrote:
>>>> 2. My last pull request has rotten for 6 months now.
>>>
>>> Sorry about that.
>>
>> No problem. Thanks for merging!
>
> Speaking of imports and dependencies, there was a dependency graph for Phobos that was circulating at some point. It used a script in conjunction with a graph printing program (such as dot or viz). Where is it?
>
> Thanks,
>
> Andrei

Here:

http://forum.dlang.org/thread/humcf2$2ufd$1@digitalmars.com

-- 
Simen