* Jiří Zárevúcky wrote, On 30/06/09 15:59: > Dne 30. červen 2009 16:50 Jiří Zárevúcky <[email protected]> napsal(a): > >> 2009/6/30 Sam Liddicott <[email protected]>: >> >>> The question is: >>> How shall vapi files specify: >>> >>> that an argument may be any type >>> that an argument may be a non-type type, e.g. a type symbol or identifier >>> >>> Jürg has suggested CCode attributes; so we could try to wrap these examples >>> like this: >>> >>> >> I think it would be much nicer to define them simply as "pseudo-types" >> with proposed CCode arguments instead being keywords. Decorated "void" >> type is quite ugly. >> >> Or is there some reason why this isn't a good idea? >> >> > > Another thought occurred to me. CCode attributes are currently not > propagating into documentation, for the reason that they are low-level > "implementation details" that programmer should not care about. So by > actually specifying the type of information passed via attribute, we > would be breaking that presumption. Not mentioning requiring to > specially handle these special cases in the documentation, which would > in turn be ugly to read. > I would prefer to avoid ccode attributes; and we still have the choice to put the "magic" in the vapi definition, or in the caller.
In the hacky patch I had provided, the vapi was typeless and the caller had to use typeof(ValaType) in order to emit the compact class C type. I think I prefer the magic to be in the vapi file, with (what you call) pseudo-types of: "typesymbol", "identifier" and "any" (I know "any" has come up before), after the fashion of python. Maybe psuedo types of number, pointer, string, class would be helpful; but here I see Jürg's point that this is taking Vala away from it's intended direction and even looks like a distraction, but it's also like a young actress suddenly becoming ashamed of her parents after getting her first film part. I also have a feeling what Jürg means when he suggests generics so that these unclean typesymbols and identifiers (although vala might emit them) don't have to appear in the pure vala code - but then how to express them in vala code? In my current typesymbol cases, the type can be inferred from the LHS of the expression, but it is also confusing that the type of a macro expression is not fixed - especially when it does a cast to a type it had as a parameter. But maybe vala could stretch to passing the type of the LHS as a function argument: class Thing new_thing = talloc_new(owner); which becomes in C struct compact_class_thing* new_thing = talloc_new(owner, struct compact_class_thing); perhaps by means of this vapi: [CCode LHS_typesymbol="1"] talloc_new(void* owner) But that would only cover this specific case, where the typesymbol is used somewhere in that vala statement. Which leads me to say that if we can accept that there is no neat way to incorporate such loose typing into vala (worse than gtype boxing!), then maybe we can just go for the quick and dirty way after all, and let projects that integrate with such API's use naked type symbols etc. After all C# also has it's un-managed code for a reason :-*( Sam
_______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
