GNOME.org
 

Re: [Vala] Gee vala libgda LINQ

Yes, I feel there is nothing new in Linq. They assemble the functional
parts of other languages, like Haskell, Python, and others, with the inline
SQL syntax that exists in Cobol, ABAP, and other older languages.

However the result of the mix is very practical and usefull for data heavy
apps like database, webservices, json/jsonp services.

I feel also that the infrastruture needed is already in a good shape. The
libgda and libgee seems to have almost all features required done as
pointed by you and Daniel.

We were talking about the missing language features that should contribute
do implementing Linq like functionality and should also improve the
language itself but no abuse language desing.

I don't know what changes are desired or acceptable for vala desing.
I'm just wondering if the change would be well accepted from vala hackers.

2013/12/8 Maciej Piechotka <uzytkownik2 gmail com>


Sorry for late response - I've had long week and I'm still catching up
with email backlog.

The core features should be in Gee already - it's just called
Traversable instead of Selectable. The 'select' part is just named a
'map' (naming in general is Haskell-inspired then SQL/LINQ-inspired).



Yes, Luca also pointed to this.

For doing this map I think that vala need some new language features:
1. Object initialization ( already in vala )
2. Anonymous objects ( only in C#/.net )
3. Type aliasing ( only in C# )

For understanding this consider the following example in Linq/C# that gets
some fields in some records from some database tabel and put in a list with
a anonymous type declared in local scope:

var query = from myalias in dbcontext.mytable
            where myalias.id == 15
            select new {
                myalias.id,
                newmembername = myalias.name,
                somevalue = myalias.value
            };

This free the developer of declaring a type for local use.
C# creates a anonymous type (a class declaration without name) infering the
property types from the types from properties given in the select new.
Mytable is just a plain object class in C# code and DBContext is the Linq
implementation:

public class MyTable
{
    int id { get; set; }
    string name { get; set; }
    double value { get; set; }
};

public class dbcontext: DataContext
{
    public DBSet<MyTable> mytable { get; set; }
};

It would not be so useful from libgee perspective but might be much more

from libgda one is ability of operating on AST syntax (I believe LINQ
have this ability but last time I've done anything in C# was ~9 years so
I may be wrong). Otherwise:



C# has the ability to inspect the AST using ExpressionTrees. At compile
time they evaluate like common expression, except they don't optimize, but
at runtime the execution builds a AST tree instead of evaluating the
expression.
In the example above, the 'query' variable will get a 'IQueryable' type
that contains the expression tree.
For get the results of the expression you should invoke the evaluation of
the AST tree from Linq simply by using the objetct like:

var newlist = query.ToList();

or

foreach(var item in query)
{
   print("%d - %s - %f", item.id, item.newmembername, item.somevalue);
}

So, with this way the developer use the compiler type inference to assist
him. In this case the compiler check the names and types of the class and
properties.

In a normal database application with hundreds of tables/classes and
thousands of queries this is a real performance boost because the compiler
catch the erros at compile time cutting the time of testing the erros at
runtime.

    select name from gdacollection where id = '123




Personally I think the Linq syntax is to obstrusive.
In the same example above, we can rewrite the syntax so it would be much
more consistent with vala design. For example:

var query = dbcontext.from(myalias => Mytable)
           .where(myalias.id = 123)
           .select({
                myalias.id,
                newmembername = myalias.name,
                somevalue = myalias.value
            });



would be suboptimal (query by primary key is something any database
should do before breakfast but from straightforward proposition it would
copy all the data into local memory and traverse it).



Yes, this is not acceptable at all.
For this AST handling and result serialization comes handy and conveniently.

I hope this could help to undertand what are the benefits of these features.
Please, let us know your opinion. This looks interesting?
What is needed? What is the effort?



On Tue, 2013-12-03 at 20:07 -0600, Daniel Espinosa wrote:




2013/12/3 Juarez Rudsatz <juarezr gmail com>
        I checked the samples and some parts of the code.
        Nice work. :-)

        Regarding language support, it seems to remain a good amount
        of work to be done yet.


Do you mean Vala features right?

        I'm counting the language features that will be necessary:
        - Object serialization


Are you mean write some where. For XML serialization we have Vala's
GXml project[1]. On GXml's serialization branch, you'll find my work
on GObject serialization to XML, comparable with .NET but, I think
more flexible[2].

        - Anonymous types

        - Expression and type introspection
        - Type aliasing...
        - Syntax changes


At the end a Collection have objects with a set of properties, a
SELECT expression is a filter of that set of objects and a set of
properties. They could be stored in a DbRecord (as for libgda's
GdaData [3] ) to save memory and adding something like
"Methods_With_Syntax_Support" [4] , Vala compiler could transform:


     var selection = select name, salary from employees where id =
"123";

     stdout.printf (@"$(selection.name) / $(selection.salary)");



to:

       var _tmp_ = new ArrayList<Employee> ();
       _tmp_.add_all ( ((Traversable) employees).filter(
                              (g)=>{ return id.equals (g) true :
false; });

       var selection = ((Selectable) _tmp_).get_fields ("name",
"salary");

       if (selection.size != 1)

          throw new SelectableError.MULTIPLE_VALUES_TO_SINGLE ("...");

       var _tmp2_ = selection[0].get_field("name");

       var _tmp3_ = selection[0].get_field("salary");
       stdout.printf (@"$(_tmp2_) / $(_tmp3_)");

        What level of support you are planning?


Because I haven't used LINQ before, I don't know most of its features.
Just think about to allow:


a) Use a SQL like syntax to filter objects and properties, by adding
support to Vala compiler to generate corresponding Vala or C code

b) Object collection must implement at least Gee.Collection and its
items must be Gee.Comparable and Selectable

c) Add a Selectable interface to Gee to allow introspect objects
properties and create a Collection with desired DbRecord set of
values.



I don't think mimic LINQ is correct. May we can do better, but is
necessary to define use cases.


The only one I have in mind is:


a) select {list-of-fields} from {collection-object} where {condition}


For this simple expression Vala's compiler should generate required
code to:


a) Check for collection-object is a GObject implementing
Gee.Collection and its elements must be Gee.Comparable and Selectable
b) Check for list-of-fields are public properties in collection-object

c) Check for condition is using collection-object 's public properties

d) Generate a Predicate<G> delegate function to find object required
objects

e) Fill a Gee.Collection with filtered objects

f) Generate a Gee.Collection from Selectable, that produce rows and
values/columns (with name=properties' name)

        It would be well received by upstream developers?

Really don't know. I'm CC to Vala and Gee lists to hear them about
this idea.

        I'm planning a new architecture for ouro next applications and
        considering vala. But the type safety and language support are
        the strengths of linq we really appreciate.

        I'm planning to help someway, but I have a long way yet to be
        produtive.

        Regards

        Juarez


[1] https://git.gnome.org/browse/gxml
[2] https://git.gnome.org/browse/gxml/log/?h=serialization

[3] https://git.gnome.org/browse/libgda/tree/libgda/data

[4]


https://wiki.gnome.org/Projects/Vala/Tutorial#Methods_With_Syntax_Support



        Em 03/12/2013 16:35, "Daniel Espinosa" <esodan gmail com>
        escreveu:

                You can see a preview of my work on current stable
                libgda.

                I've finished interfaces and implementations under
                GdaData name space.

                I've added some documentation just use
                --enable-vala-extensions --gtk-doc (some other
                switches are required) to see it installed.

                Missed Selectable interface or implementation.

                I would like to add syntax support on Vala compiler in
                order to have LINQ like one.

                For now is very easy to access to data using GdaData
                objects, see unit tests for more examples.

                El dic 3, 2013 10:03 a.m., "Juarez Rudsatz"
                <juarezr gmail com> escribió:
                        Hi,


                        I found that you have been working in a
                        possible implementation of LINQ in vala [1].

                        I see that you have made good progress
                        regarding this support.
                        I want to know what is the current status.

                        What's missing yet? How is the work for
                        getting basic support ?


                        Regards

                        Juarez


                        [1]


https://mail.gnome.org/archives/vala-list/2011-December/msg00140.html





--
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
_______________________________________________
libgee-list mailing list
libgee-list gnome org
https://mail.gnome.org/mailman/listinfo/libgee-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]