On 12/11/2013 06:04 AM, Zack Corr wrote:
let original: Option = from_str("1");
let result: Option = original?.to_float()?.sqrt();
You can already say
let original: Option = Some(1);
let result: Option = original
.and_then(|f| f.to_f64())
.map(|
Before of release 1.0, it would be very good if it's added to the
package standard a generic interface to be implemented by the packages
of SQL drivers.
As example, see packages "database/sql" and "database/sql/driver" in the
Go's library:
http://golang.org/pkg/database/
I'll be glad volunteering for this task, however I'm new in rust so I may
need to have some mentoring for this...
I would be inspired by the python interface:
https://pypi.python.org/pypi/MySQL-python/1.2.4
-
Gaetan
2013/12/11 John Mija
> Before of release 1.0, it would be very good if i
On 2013-12-11, at 15:24 , Gaetan wrote:
> I'll be glad volunteering for this task, however I'm new in rust so I may
> need to have some mentoring for this...
>
> I would be inspired by the python interface:
> https://pypi.python.org/pypi/MySQL-python/1.2.4
A better inspiration than a specifi
Python has the advantage of dynamic typing, and Go runtime type
assertions and variadics. Their interfaces probably aren't /too/ good
for inspiration, especially Python's.
See rust-postgres (https://github.com/sfackler/rust-postgres) for an
existing DB binding. I think it's fairly idiomatic and an
I agree python dbapi is pretty simple to use due to the dynamic nature of
types in python.
I like this rust postgre binding, I can't see why it cannot be extended to
support mysql?
Actually, my main reference is sqlalchemy but it's a step much higher in
term of abstraction of the DB.
-
Gaeta
On 12/11/13 3:01 AM, John Mija wrote:
Before of release 1.0, it would be very good if it's added to the
package standard a generic interface to be implemented by the packages
of SQL drivers.
We aren't likely to block 1.0 on this. Instead of stabilizing all
libraries once and for all in 1.0 lik
The interface can be made generic, but it'd require HKT and potentially
some more work on removing spurious conflicting trait implementation
warnings. It only uses trait objects for query parameters where you
actually need an array of distinct types implementing an interface. I've
also found that g
While I'm all in favor of having a standard SQL interface, but I don't
think it needs to be a part of Rust's standard library. Instead I feel this
is one of those libraries that can live outside of rust proper and be
blessed by the community as being the standard SQL framework. Once rustpkg
is done
Sounds good me.
I believed that the API would be frozen in 1.0 like Go. Besides, that
version is going to attract many developers and without a generic API to
build SQL drivers, it would be very chaotic to have different clients of
SQL engines with a different API instead of to have the same o
On Wednesday 11 December 2013 17:27:43 John Mija wrote:
> Sounds good me.
>
> I believed that the API would be frozen in 1.0 like Go. Besides, that
> version is going to attract many developers and without a generic API to
> build SQL drivers, it would be very chaotic to have different clients of
My belief is that a generic interface to DBs is only useful because that way
you can write other DB-driven libraries that don't care about the details of
the DB. I don't think I've ever seen code in the wild that uses this
functionality though (although, admittedly, I haven't looked at a lot of
most of the time:
- either you rely on full abstraction of the db in your library (sql
alchemy), ie, the library gives you a complete abstraction of the
views/tables/ etc of the sql database.
- either you just use the SQL statements with minor data type binding
(dbapi).
i ve used both, especially
On 12/11/2013 03:24 PM, Gaetan wrote:
I would be inspired by the python interface:
Yes, on this point python just does "the right thing".
Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 12/11/2013 07:14 PM, Kevin Ballard wrote:
My belief is that a generic interface to DBs is only useful because that way
you can write other DB-driven libraries that don't care about the details of
the DB. I don't think I've ever seen code in the wild that uses this
functionality though (alth
On 12/11/2013 06:04 PM, Patrick Walton wrote:
We aren't likely to block 1.0 on this. Instead of stabilizing all libraries once
and for all in 1.0 like Go did, we're taking a gradual approach to libraries
similar to that of node.js, in which 1.0 will have some library modules stable
and some modul
as another point in the design space, a pretty idiom for SQL style dbs in
haskell is the *-simple family of libs
postgres simple
http://hackage.haskell.org/package/postgresql-simple-0.3.7.0/docs/Database-PostgreSQL-Simple.html
mysql-simple
http://hackage.haskell.org/package/mysql-simple-0.2.2.4/d
If at some point of time something like haskell do notation or scala for
comprehension will be implemented in rust then it would be worth to look at
slick:
http://slick.typesafe.com/
Example from slick home page:
//
@table("COFFEES") case cl
On 12/12/13 09:57, Carter Schonwald wrote:
as another point in the design space, a pretty idiom for SQL style dbs
in haskell is the *-simple family of libs
postgres simple
http://hackage.haskell.org/package/postgresql-simple-0.3.7.0/docs/Database-PostgreSQL-Simple.html
mysql-simple
http://hack
Yes, but Rust doesn't have HKT. I was suggesting it on this basis. I'd
prefer `do` as well.
On Wed, Dec 11, 2013 at 5:25 PM, Ziad Hatahet wrote:
> On Tue, Dec 10, 2013 at 9:04 PM, Zack Corr wrote:
>
>> I think the Monadic null operator (a.k.a. safe property access operator)
>> would be pretty
It could certainly be implemented now, if it was restrictive to builtin
monad types - like `Option`. The real question would be what sort of syntax
fits in with Rust. Would there be a new bind operator, or have `bind`
instead of `let` in `do` blocks or just reuse let and have any option types
be au
If `do` is going away from being used as syntactic sugar to invoke
functions with closure arguments, would it be a possibility to use it here?
--
Ziad
On Wed, Dec 11, 2013 at 6:30 PM, Zack Corr wrote:
> It could certainly be implemented now, if it was restrictive to builtin
> monad types - lik
Suppose I have an object `foo` of some type that implements the trait
`Foo { fn blah() {} }`, and I see an ExprMethodCall `foo.blah()`, how
do I get the DefId of the trait method `blah`?
The following is what I have tried so far. The particular part I'm
concerned about is the match arm for `typeck
23 matches
Mail list logo
