Re: [Vala] Set implementation and/or associative arrays

[Alessandro Pellizzari <alex amiran it>]

Il giorno mar, 22/01/2008 alle 16.00 +0100, Jürg Billeter ha scritto:

> > error: Return type and/or parameters of overriding method `Row.get' do
> > not match overridden method `Gee.Map.get'.

> It's a limitation of the current generics support. I hope to get it
> fixed soon. Can you please file a bug in Bugzilla?

Done: http://bugzilla.gnome.org/show_bug.cgi?id=511286

I hope I wrote it correctly. I didn't know how to explain it better. :)

> > And could we have "magic methods" without implementing interfaces
> > (__set(), __get(), __toString(), __call(), etc as in PHP/Pyhton/D)? :)
>
> The interface approach makes more sense for Vala and GObject/C, in my
> opinion.

OK, I unerstand what you mean.

And would it be possible to have interfaces to define those methods and
have them called automatically when needed? For example:

/* Serialize an object, be it an array, a Map, a Set, etc. as a string.
   For example: to encode it in JSON or XML
   Unserialize should recreate the object properties from a string s.
*/
interface Serializable
{
 public string serialize();
 public bool/void unserialize(string s);
}

/* I can't come up with a better name :)
   This should transform the object to string.
   Example: int a = 5; printf("%s", a);
            should transparently call a.toString()
*/
interface Stringable
{
 public string toString();
 public ??? fromString(); // optional?
}

/* This should be automatically called when the user calls
   a non-existant method in the class
*/
interface Callables
{
 public ??? call(string methodname, Array/Hash parameters);
}

/* Can't come up with a name at all :)
   these method should get called automatically when the user
   accesses a non-existant attribute in the class, as in 
   o = new Obj();
   o.foo = "bar";
*/   
interface Something
{
 public set_attr(string attr, V/Pointer? value);
 public V/Pointer? get_attr(string attr);
}

I think all those functionalities require compiler assistance.
They would make vala more "dynamic", and maybe are difficult to
implement efficiently, but I think they would simplify development a
lot.

Thanks again for your work.

-- 
Alessandro Pellizzari