Re: [Vala] vala libgda LINQ
Luca, Daniel,
LINQ is just some kind of syntax for some functional
programming aspects. It's about to be a 1:1 mapping with
filter-map, also fold and scan..
You are mostly correct about LINQ to Objects.
In this case the .net designers capitalized from the popularity of LINQ to
SQL and used the same syntax and naming to add this support to .Net.
I also agree that is not necessary to force the language syntax to get the
desired results.
But LINQ to Entities and LINQ to SQL are different beasts:
Quoting [1] :
LINQ-to-Objects is a set of extension methods on IEnumerableT that
allow you to perform in-memory query operations on arbitrary sequences of
objects. The methods accept simple delegates when necessary.
LINQ-to-Entities is a LINQ provider that has a set of extension methods on
IQueryableT. The methods build up an expression tree (which is why
delegates are actually passed as Expressions), and the provider will
build up a SQL query based on its parsing of that expression tree.
The L2E implements a ORM that executes the following workflow:
Language syntax - Expression Tree - Query caching - SQL text - database
- serialization - collection objects in languge.
For example, in this code:
var db = new MyDatabaseContext();
var query =
from c in db.Contacts
join o in db.Orders
on c.ContactId == o.ContactId
join p in db.Payments
on p.Number == p.OrderNumber
where p.DueDate DateTime.Today()
p.PaidValue o.Amount
select new
{
ContactName = c.Name,
ContactPhone = c.Phone,
OrderNumber = o.Number,
o.Amount,
o.DueDate,
AmountPaid = p.PaidValue
};
foreach(var contact in query)
{
print(%30s %10s %8i %10f %10d %10f,
contact.ContactName,
contact.ContactPhone,
contact.Amount,
contact.DueDate,
contact.AmountPaid
);
}
What are the language features needed that I still haven't found in Vala:
1) Expression Support, type instrospection support
The whole query statement above is not evaluated locally.
Instead it builds a Expression Tree (AST) and when invocated in foreach
loop it builds a SQL Query and execute against a database, object
repository, etc...
I couldn't find in vala how to store the expression where *p.DueDate
DateTime.Today() p.PaidValue o.Amount* in a Expression tree for
using it later for building a SQL query.
2) Type Aliasing
The classes db.Contacts, db.Orders and db.Payments are aliased to c, o and
p and used after to indicate what class you are refering.
Classes could be refered twice like in Person as teacher and Person as
student.
Why this is important:
Because it binds the language type safety to the data model you have.
Database applications are just boring repetitions of user input forms,
reports and data procedures. When you change a table/class the compiler
will help you check when the name/type change will break your code.
Database aplications usually have hundreds of tables/classes and thousand
of queries and type safety cut the much of the maintanance burden.
3) Anonymous objects
Afte the query get back the results are materialized/serialized to a new
anonymous type with local scope.
In this example the select new statement creates a collection of anonymous
objects. The var query gives to the variable this anonymous type.
Why this is important:
Because it saves the cuts a lot of code for declaring a new class that will
be used once.
I hope this could help understand what the benefits of a language
integrated ORM for data intensive applications. Some things could add
flexibility to language itself.
Other features of LINQ to Entities:
a) Lazy loading
public class Person
{
string name { get; set; }
Address address { get; set; }
}
// get a record from Person table
Person friend =
from f in db.Persons
where f.Name = Luca
select f;
// Get a record from address table
print(friend.address.street);
b) Inheritance
public class Customer : Person { ... }
[1]
http://stackoverflow.com/questions/7192040/linq-to-entities-vs-linq-to-objects-are-they-the-same
[2]
http://maanshah.wordpress.com/2012/03/02/linq-to-sql-vs-linq-to-objects-vs-linq-to-entities/
2013/12/4 Daniel Espinosa eso...@gmail.com
2013/12/3 Juarez Rudsatz juar...@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
Re: [Vala] vala libgda LINQ
LINQ is just some kind of syntax for some functional programming
aspects. It's about to be a 1:1 mapping with filter-map, also fold and
scan..
For example:
select field1,field2 from collection where field3==value
can be written as:
collection.filter((r) = r.field3==value).map((r) = {r.field1, r.field2});
Obviously, LINQ is not only that, but that's a good approximation.
That said, implement filter, map and fold in your collections library
and you can avoid the LINQ syntax :-)
Consider libgee has filter, map, fold and scan with which you can
implement a large subset of LINQ, including aggregate operators.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala libgda LINQ
2013/12/4 Luca Bruno lethalma...@gmail.com
LINQ is just some kind of syntax for some functional programming aspects.
It's about to be a 1:1 mapping with filter-map, also fold and scan..
For example:
select field1,field2 from collection where field3==value
can be written as:
collection.filter((r) = r.field3==value).map((r) = {r.field1, r.field2});
Obviously, LINQ is not only that, but that's a good approximation.
Vala has provide nice/sexy syntax for GObject/C programing. Have added lot
of new features, witch have been possible to write in C but with lot of
lines of code. I love Vala because allows me to be more productive, even
Genie allows more simplification on Vala's syntax.
I think that former syntax are more productive and easy to read than the
last. Could allow to work with-in Vala's code with lot of data from a
DataBase or any other data source. GdaData objects and interfaces allows to
access that data using just GObjects and Vala code, abstracting most of
internal operations and mapping to properties and methods, and allow to use
Gee collections to make more easy to access to data using by code; but
could reach a next level by adding some syntax support on Vala for SQL like
queries.
I know that adding syntax support may is not easy or is far from Vala
principles.
Then I would like to see a way to allows Vala compiler with a mechanism of
PLUG-INS for syntax support. Then GdaData could add its own plug-in for SQL
syntax when it is installed.
The above allows not to distract Vala from its principles, but allows to
others add syntax for specific task that makes more easy/productive and
clear way to do the same.
Less code and clear syntax, allows more productive less errors.
That said, implement filter, map and fold in your collections library and
you can avoid the LINQ syntax :-)
Consider libgee has filter, map, fold and scan with which you can
implement a large subset of LINQ, including aggregate operators.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
--
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)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala libgda LINQ
On 04/12/2013 16:52, Daniel Espinosa wrote: Vala has provide nice/sexy syntax for GObject/C programing. Have added lot of new features, witch have been possible to write in C but with lot of lines of code. I love Vala because allows me to be more productive, even Genie allows more simplification on Vala's syntax. I think that former syntax are more productive and easy to read than the last. Could allow to work with-in Vala's code with lot of data from a DataBase or any other data source. GdaData objects and interfaces allows to access that data using just GObjects and Vala code, abstracting most of internal operations and mapping to properties and methods, and allow to use Gee collections to make more easy to access to data using by code; but could reach a next level by adding some syntax support on Vala for SQL like queries. I know that adding syntax support may is not easy or is far from Vala principles. Then I would like to see a way to allows Vala compiler with a mechanism of PLUG-INS for syntax support. Then GdaData could add its own plug-in for SQL syntax when it is installed. The above allows not to distract Vala from its principles, but allows to others add syntax for specific task that makes more easy/productive and clear way to do the same. Less code and clear syntax, allows more productive less errors. Plugins are planned, but not for changing the syntax. Plugins will be able to transform the ast into other ast, but neither semantics nor syntax are allowed to change. Consider this alternative, doable with such plugins: select(Class.foo, Class.bar).from(collection).where(equal(some_field, some value)). Collection may be anything from an array to a gee collection to anything. The plugin in this case can generate the relevant code by doing the necessary magic, and it has all the information about the collection from the ast. However, such plugins will not be there anytime soon, there's first a huge experimental branch to be merged (yet to be completed). ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala libgda LINQ
2013/12/4 Juarez Rudsatz juar...@gmail.com
Luca, Daniel,
LINQ is just some kind of syntax for some functional
programming aspects. It's about to be a 1:1 mapping with
filter-map, also fold and scan..
You are mostly correct about LINQ to Objects.
In this case the .net designers capitalized from the popularity of LINQ to
SQL and used the same syntax and naming to add this support to .Net.
I also agree that is not necessary to force the language syntax to get the
desired results.
But LINQ to Entities and LINQ to SQL are different beasts:
Quoting [1] :
LINQ-to-Objects is a set of extension methods on IEnumerableT that
allow you to perform in-memory query operations on arbitrary sequences of
objects. The methods accept simple delegates when necessary.
LINQ-to-Entities is a LINQ provider that has a set of extension methods
on IQueryableT. The methods build up an expression tree (which is why
delegates are actually passed as Expressions), and the provider will
build up a SQL query based on its parsing of that expression tree.
The L2E implements a ORM that executes the following workflow:
Language syntax - Expression Tree - Query caching - SQL text -
database - serialization - collection objects in languge.
For example, in this code:
var db = new MyDatabaseContext();
var query =
from c in db.Contacts
join o in db.Orders
on c.ContactId == o.ContactId
join p in db.Payments
on p.Number == p.OrderNumber
where p.DueDate DateTime.Today()
p.PaidValue o.Amount
select new
{
ContactName = c.Name,
ContactPhone = c.Phone,
OrderNumber = o.Number,
o.Amount,
o.DueDate,
AmountPaid = p.PaidValue
};
foreach(var contact in query)
{
print(%30s %10s %8i %10f %10d %10f,
contact.ContactName,
contact.ContactPhone,
contact.Amount,
contact.DueDate,
contact.AmountPaid
);
}
What are the language features needed that I still haven't found in Vala:
1) Expression Support, type instrospection support
The whole query statement above is not evaluated locally.
Instead it builds a Expression Tree (AST) and when invocated in foreach
loop it builds a SQL Query and execute against a database, object
repository, etc...
I couldn't find in vala how to store the expression where *p.DueDate
DateTime.Today() p.PaidValue o.Amount* in a Expression tree for
using it later for building a SQL query.
I would like to create a Selectable and Expression interface, using GDA as
back-end to implement them. With that in mind we can create programatically
an expression tree to be parsed on demand to get required objects. GdaData
allows you to run queries on-demand, you haven't any SQL command executed
when objects are created, but when data needs to be retrieved.
Then with a mechanism to parse expressions for any kind of data we can
create queries when required. GDA have a SqlParser for strings expressions
and SqlBuilder for programatically created ones, then just put this
infrastructure together to allows:
a) Data collections (Gee ones or Database ones) be queryable.
b) Create plug-ins for syntax support to easy and clean code declarations
2) Type Aliasing
The classes db.Contacts, db.Orders and db.Payments are aliased to c, o and
p and used after to indicate what class you are refering.
Classes could be refered twice like in Person as teacher and Person as
student.
Why this is important:
Because it binds the language type safety to the data model you have.
Database applications are just boring repetitions of user input forms,
reports and data procedures. When you change a table/class the compiler
will help you check when the name/type change will break your code.
Database aplications usually have hundreds of tables/classes and thousand
of queries and type safety cut the much of the maintanance burden.
3) Anonymous objects
Afte the query get back the results are materialized/serialized to a new
anonymous type with local scope.
In this example the select new statement creates a collection of anonymous
objects. The var query gives to the variable this anonymous type.
Why this is important:
Because it saves the cuts a lot of code for declaring a new class that
will be used once.
I hope this could help understand what the benefits of a language
integrated ORM for data intensive applications. Some things could add
flexibility to language itself.
Other features of LINQ to Entities:
a) Lazy loading
public class Person
{
string name { get; set; }
Address address { get; set; }
}
// get a record from Person table
Person friend =
from f in db.Persons
where f.Name = Luca
select f;
// Get a record from address table
print(friend.address.street);
b) Inheritance
public class Customer : Person { ... }
[1]
http://stackoverflow.com/questions/7192040/linq-to-entities-vs-linq-to-objects-are-they-the-same
Re: [Vala] vala libgda LINQ
2013/12/4 Luca Bruno lethalma...@gmail.com On 04/12/2013 16:52, Daniel Espinosa wrote: Vala has provide nice/sexy syntax for GObject/C programing. Have added lot of new features, witch have been possible to write in C but with lot of lines of code. I love Vala because allows me to be more productive, even Genie allows more simplification on Vala's syntax. I think that former syntax are more productive and easy to read than the last. Could allow to work with-in Vala's code with lot of data from a DataBase or any other data source. GdaData objects and interfaces allows to access that data using just GObjects and Vala code, abstracting most of internal operations and mapping to properties and methods, and allow to use Gee collections to make more easy to access to data using by code; but could reach a next level by adding some syntax support on Vala for SQL like queries. I know that adding syntax support may is not easy or is far from Vala principles. Then I would like to see a way to allows Vala compiler with a mechanism of PLUG-INS for syntax support. Then GdaData could add its own plug-in for SQL syntax when it is installed. The above allows not to distract Vala from its principles, but allows to others add syntax for specific task that makes more easy/productive and clear way to do the same. Less code and clear syntax, allows more productive less errors. Plugins are planned, but not for changing the syntax. Plugins will be able to transform the ast into other ast, but neither semantics nor syntax are allowed to change. Consider this alternative, doable with such plugins: select(Class.foo, Class.bar).from(collection).where(equal(some_field, some value)). This could be possible using GDA and GdaData infrastructure. Just require to create some classes and interfaces. Of course this don't need a Vala plug-in just install GDA and enable GdaData :-) Collection may be anything from an array to a gee collection to anything. The plugin in this case can generate the relevant code by doing the necessary magic, and it has all the information about the collection from the ast. GdaData already do this. You have mapped tables, records, fields to Gee collections and implements some interfaces to allow any other to be a data provider not just databases that actually use GDA as back-end. However, such plugins will not be there anytime soon, there's first a huge experimental branch to be merged (yet to be completed). After that merge, are there any plan for plug-in support and include syntax support too? Are we need to go the Genie way? If Genie way is recommended, then we need to fix missings in GdaData to allow basic programically query execution and then think about to create Vala/Genie syntax. -- 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) ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala libgda LINQ
2013/12/3 Juarez Rudsatz juar...@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 ArrayListEmployee ();
_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 PredicateG 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 eso...@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 juar...@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)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
