Re: [Vala] Generics: constraints and 'new T ()' on type parameters?

[Christian Hergert <christian hergert gmail com>]

I wrote a datamapper (rather than an ORM) a while back in Vala.  I
don't think anyone is really using it, but it might be an example for
various problems or questions you run into.

http://git.dronelabs.com/git?p=users/chris/godm.git;a=summary

It does let you do some neat stuff (and creates objects for you) like

Person.find(Condition.str_equal("firstname", "Christian")).slice (0,
10).each(p => {
    stdout.printf ("%s\n", ((Person)p).lastname);
});

It also has various backends (called contexts) for data sources such
as Json or Sqlite.

HTH,

-- Christian

On Thu, Feb 26, 2009 at 4:52 PM, Sam Danielson <samdanielson gmail com> wrote:
> I'm writing some ORM where a database view is wrapped in a factory
> object that produces records. Ideally I would think a Factory <T>
> should be able to return new T's but I can't figure out how to do
> this. The work around is to return the Record base class and then
> upcast, or put virtual upcasting functions in all of the
> derived Factory classes. Yuck.
>
> Is there a fundamental reason why this cant work?
>
> class Foo {}
> class Factory <T> {
>        public static T make () {
>                return new T ();
>        }
> }
>
> And is there a plan to implement type parameter constraints? Something like...
>
> class Factory <T:Object> { ... }
>
> The compiler may then prove that it is okay to 'new T ()'
>
> PS. I can slip the following by the type system without a complaint. Should I
> file a bug?
>
> class Foo {}
> class Factory <T> {
>        public static T make () {
>                return new Foo ();
>        }
> }
>
> LLAP,
> Sam Danielson
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list