On Sat, 16 May 2015 15:20:01 +0200, Sönke Ludwig wrote:
Am 16.05.2015 um 14:21 schrieb Suliman:
The problem is that you didn't specify the API interface.
Why I should to specify API interface? It's element of good design, but why I can't create simple class without it?
This restriction has been chosen to ensure a working REST server/client
duality. By always working on an interface, both are guaranteed to work
and to result in exactly the same REST protocol. For cases where only
the server is planned to be used, the restriction could in theory be
lifted...
In theory, but in practice it'll add some complexity to the REST generator, because an interface defines exactly what you want to expose.
If you only rely on the object, you'll have way more things exposed than you intend to. For example, should you expose the base class' methods ? When the base class is Object, you surely don't want to expose 'opCmp' / 'opEquals' / 'toString'. But when it's not, what should you expose ? What if you do want to expose an overriden 'toString' in a base interface ?
And the killer of all: Depending on the stage of compilation, __traits(allMembers) might not returns all members (For example issue #1040 is not possible anymore because of a change in the Fronend...)
I tried to lift this constraint at some point, but realized it was not worth the trouble.