On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation nicely separated out
from
usage, you really do. Which is a major part of my
requirements.
Well, in my example above, everything is nicely separated,
easy to use,
yet quite flexible. And still there is no Java-style OOP. Do
you have
any examples, where the use of classic OOP would provide a
strictly
superior design?
You're using templates. While this might be ok for image
library.
I cannot use this for the windowing library. The implementation
may not be known and must be plugable at runtime.
The reality is, just because you say you know about something
at compile time doesn't mean the system that runs a program
does.
I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual platform
that will be used, you can still choose at RT the correct
template. Example:
// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
enforce(false, "Unknown platform: " ~
platformNameRTArg);
foreach (platform; EnumMembers!Platform)
case name.stringof:
// Use std.experiment.typecons.Wrap if you need
a common type.
return getWindow!(name, CTArgs);
}
assert (0);
}
But that's besides the point. Even with OOP, your return type can
be an interface that has template parameters like allocators,
policies, etc. You're providing some the arguments at CT and the
rest of the return type is dynamically polymorphic. E.g.:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);
My point is that there's no need for IAllocator, even if you want
to use OOP so badly.
But in most cases you will either write different code for
different platforms, making interfaces unnecessary, or you would
be able to hide the differences behind a struct.
And when the allocator and the other policies are template
parameters you will know at CT that your code is @nogc.
