On Tue, 2017-10-24 at 13:58 -0500, Federico Mena Quintero wrote:
Hey, all! I'm making very good progress with the rewrite of gnome-class. I've figured out how to port it gradually from lalrpop and the old proc- macro scheme of things, to proc-macro2 and syn/quote.
Good work :) See below for my opinion on the colour of the bikeshed, feel free to ignore everything ;)
By default, the answer to many things here is "what does Vala do?" :) This is probably often the right thing syntax-wise. We can make it more Rust-like as needed.
Sounds like a good guideline, and C# as a fall-back.
"struct CounterPrivate" is your private struct. Each class must have one and only one such structures.
Do you plan to also add support for public fields in the instance struct?
private_init() is a mandatory function that gets called during initialization; you return an initialized private struct, and *that* becomes the initial value of what gets put in the g_type_class_add_private() chunk.
This should probably take the instance as parameter, or a different function for hooking into instance_init would be useful. To set-up any things that might be necessary for the base-class to properly initialize everything.
As an alternative, I want to make it possible to specify #[derive(Default)] for your private struct, and thus not having to specify a private_init():
Then it should also be possible to impl derive for the struct manually, the default derived impl is not always possible/correct :)
Constructors
============
Vala supports a construct{} block, which gets called after all
(construct-time?)
properties have been set. It uses GObjectClass::constructor. I
haven't decided
Could also use a construct {} block for that, it seems like a
reasonable choice. Similarly for class and base construct blocks.
on this yet, nor on how the following from Vala would work:
public MyConstructor (int a, int b, int c) {
Object (some_construct_only_prop: a, some_other_prop: b); //
construct superclass
this.my_own_prop = c;
}
I assume this would only take CONSTRUCT properties, and not all of them, and there can only ever be a single constructor like this?
Problem: how would the code generator know which superclass struct has the .foo field in order to override it? Should we specify this overriden method like override fn SuperClassName::foo(&self, ...); ?
Seems ok to me, it would also be a solution for an interface and base- class having the same method name.
Visibility: the code generator assumes that all the "fn" that you put inside a class are public. Should we instead allow "fn" and "pub fn"?
Yes
Should virtual methods be declared as "virtual pub fn" correspondingly?
virtual implies public IMHO
Third alternative, also Rust-like, with "impl" items outside the
class:
gnome_class! {
class Foo: Superclass, Iface1, Iface2 {
// ...
}
impl Iface1 for Foo {
fn method_1(&self, ...) {
// code
}
}
impl Iface2 for Foo {
fn method_2(&self, ...) {
// code
}
}
}
I prefer this, but you don't even have to specify the interfaces on the class line then. It's redundant there.
Creating new interfaces
=======================
I haven't decided this yet. Maybe something like
gnome_class! {
interface Foo {
virtual fn blah(&self, x: i32) -> bool;
virtual fn bleh(&self, y: *const c_char);
}
}
I.e. make it similar to "trait", except that the "virtual" keywords
are there to remind you that you are not in Rust land?
I like that
Signals ======= [...]
All looking good to me
I haven't though of how to specify signal accumulators, or if we even need them. Is there a non-obscure case that needs them?
We use them quite often in GStreamer. You basically need them whenever you have a non-trivial return value, or you want to use your return value to decide if further signal handlers have to be called. I can give examples if needed. You could provide them by name in the signal attribute. What about the class/default handler, how would you handle that?
Properties ========== I took some notes about this, but they are far from final. Vala has good examples on what the syntax may look like; it borrows from C#, which is nice.
The C#/Vala way seems good to me.
Attachment:
signature.asc
Description: This is a digitally signed message part