Re: [Vala] Libgee's Roadmap proposal

[Jan Hudec <bulb ucw cz>]

Jiří Zárevúcky <zarevucky jiri    > writes:

> Dne 21. červenec 2009 17:06 Jiří Zárevúcky <zarevucky.jiri <at> gmail.com>
> napsal(a):
> > 2009/7/21 Julien Fontanet <julien.fontanet <at> isonoe.net>:
> > > How is that possible, the methods' signatures do not match:
> > >  - Collection.add (G item) vs. Map.set (K key, V value)
> > >  - Collection.contains (G item) vs. Map.contains (K key)
> > >  - Collection.remove (K item) vs. Map.remove (K key)
> > >
> > > Collection implements Iterable which provides this method: Iterator<G>
> > > iterator () whereas it should be Iterator<Pair<K, V>> iterator () for 
> > > Map.
> >
> > The trick is that Map<K, V> would implement interface
> > Collection<Pair<K, V>>. Unless there is some serious bug in Vala, it
> > would work perfectly. The .NET framework does it this way and it
> > always worked perfectly for me.
>
> Ah, I misunderstood your point. You mean that there already are
> methods with different signatures then required by the interface.
>
> Well, in that case, it's also simple. The colliding methods have to be
> implemented explicitly. nobody would use contains and remove with Pair
> on map anyway. I just don't know how is it with support for explicit
> interface member implementations in Vala.

Considering how interfaces are implemented in Glib, it should be 
implementable.  To overload an interface method, a pointer in the class
object is set to a pointer to the implementing function. So for explicit
interface implementation, the generator would create a function with
different name (<class>_<method>_<interface> instead of <class>_<method>
probably) and assign it to the appropriate member.  Than it would have to
notice it when generating the new method of the same name (which has cname
<class>_<method>, so it does not conflict) and skip setting that pointer.

> From quickly glancing at the generator code it does not look like being 
implemented (it was a very very quick glance, though), but it should be
doable. Care just has to be taken to avoid the named constructors feature,
which uses similar syntax.

Regards,
Jan

--
 - Jan Hudec <bulb ucw cz>