Re: [Vala] Emitting type symbols, identifiers and type-less parameters. bugzilla 558106

["Sam Liddicott" <sam liddicott com>]

* Jiří Zárevúcky wrote, On 30/06/09 15:59:

Dne 30. červen 2009 16:50 Jiří Zárevúcky <zarevucky jiri gmail com> napsal(a):
  

2009/6/30 Sam Liddicott <sam liddicott com>:
    

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