On 01/28/12 17:28, Kagamin wrote:
> On Tuesday, 24 January 2012 at 16:09:21 UTC, Artur Skawina wrote:
>> and all of these will result in identical code being emitted.
> 
> what if
> struct Rectangle
> {
>  GdkRectangle r;
>  alias r this;
> ... methods ...
> }
> 
> Will a different code be emitted?
> Will alias this work with C api?

Wrapping one struct in another, with no extra fields, shouldn't
make any difference wrt the resulting code.
But i don't see any reason to do it like that, and, in addition to
having two not 100% compatible ways to refer to the same thing, it
would make some things harder and/or impossible. Things like the
pseudo struct inheritance magic (you can call methods present in
*parent* objects and the right thing will happen; the Rectangle is
not a good example for this, see the AppwWin struct in example_gtk3.d,
where eg. the last "add()" actually is a GtkContainer method, not a
GtkWindow one) and implicit conversions [1].

alias-this makes no difference for the C API, it only matters when you use the D extras.

>> And, yes, this is probably suitable for Deimos, iff part #3 is. (I see no advantage in splitting out the trivial "methods")
> 
> C bindings are a value on their own, this is probably why deimos doesn't like #3: your methods will be a burden to other users(libraries) of the bindings.
> 

The problem with splitting out the methods is that it would create another module. As it is, an app only needs to "import gtk2.gtk2;" and everything works. Having some apps use this and others use eg a "gtk2.gtkd2" would be bad. Having different identifiers (like the suggested camelCased ones) would be even worse. Let's reduce the pointless balkanization, not encourage it.

artur

[1] D needs a way to control all implicit conversions for structs/classes,
both *if* these should happen and *how*. Also *all* casts should be properly
lowered, right now you have to eg use alias-this tricks to catch implicit casts.