Should ORM be done as separate lib, or it's should become part of Phobos?

Am 06.04.2013 14:35, schrieb Suliman:
> Should ORM be done as separate lib, or it's should become part of Phobos?

Why do people want to pack everything into phobos... And better question why is it then also added to phobos (like curl, wtf)? But that's a different topic.

Because people want standards. For example people want GUI for D, but most of the people agree that it would bad idea to create 10 different GUIs, and it's better have one official GUI.

Look at .NET it's include most of things that developers need at real life. And it's one of reasons of it's popularity.

On Friday, 5 April 2013 at 17:18:01 UTC, Dicebot wrote:
> On Friday, 5 April 2013 at 16:41:53 UTC, Vadim Lopatin wrote:
>> I'm iterating through class members using __traits(allMembers, T), then accessing member using _traits(getMember,T,memberName)
>>
>> I'm not sure which one of the members with the same name will be returned by getMember... Property getter and setter have the same name...
>>
>> Is there any better way to iterate through members of class?
>
> Quoting vibe.d again :)
>
> ---
> foreach( member; __traits(allMembers, T) ) {
>     foreach( overload; MemberFunctionsTuple!(T, method) ) {
> ---

Fixed property support.

On Saturday, 6 April 2013 at 12:50:19 UTC, Suliman wrote:
> Because people want standards. For example people want GUI for D, but most of the people agree that it would bad idea to create 10 different GUIs, and it's better have one official GUI.
>
> Look at .NET it's include most of things that developers need at real life. And it's one of reasons of it's popularity.

At the same time, it's good to have some competition and alternative choices. For example, Ruby on Rails is the de facto standard for Ruby Web applications, but there are alternatives (and pretty decent ones at that). That's why I'm continuing to work on my own ORM library, which should still have a niche in SQLite-based applications because its API is designed to be lightweight and lazy.

> At the same time, it's good to have some competition and alternative choices.

It's not problem to have 2 realization. Base and alternative. To
have one base realization is always good for thous who need to be
sure that it would not be abandoned.

On Wednesday, 3 April 2013 at 14:28:37 UTC, Vadim Lopatin wrote:
> Hello!
>
> I've started implemetation of ORM in D, with annotations and interfaces similar to Hibernate.
>
> As DB abstraction layer I wrote DDBC - library with interface similar to JDBC. Only MySQL driver is implemented. PostgreSQL - in progress.
>
> Project is hosted on SourceForge: https://sourceforge.net/p/hibernated/wiki/HibernateD/ License is Boost
....
>
> Look at project wiki and unittests for more info.

Project status update:

Recent changes:
- Better convention-over-configuration support: most of annotations are non-mandatory now, inferred from field types
- Automatic creation of DB tables and indexes

Am 09.04.2013 08:27, schrieb Suliman:
>> At the same time, it's good to have some competition and alternative choices.
> 
> It's not problem to have 2 realization. Base and alternative. To have one base realization is always good for thous who need to be sure that it would not be abandoned.
I am looking forward to the date libphobos.a has 1GB in size and takes 5 hours to compile

On Wednesday, 10 April 2013 at 08:59:07 UTC, David wrote:
> Am 09.04.2013 08:27, schrieb Suliman:
>>> At the same time, it's good to have some competition and alternative
>>> choices.
>> 
>> It's not problem to have 2 realization. Base and alternative. To
>> have one base realization is always good for thous who need to be
>> sure that it would not be abandoned.
> I am looking forward to the date libphobos.a has 1GB in size and takes 5
> hours to compile

std.* may include only interfaces, e.g. like in java.sql package.
Implementations not necessary in std. Can be third party libraries (e.g. like java JDBC drivers). But standard interfaces give benefits.

Am 10.04.2013 12:26, schrieb Vadim Lopatin:
> On Wednesday, 10 April 2013 at 08:59:07 UTC, David wrote:
>> Am 09.04.2013 08:27, schrieb Suliman:
>>>> At the same time, it's good to have some competition and alternative choices.
>>>
>>> It's not problem to have 2 realization. Base and alternative. To have one base realization is always good for thous who need to be sure that it would not be abandoned.
>> I am looking forward to the date libphobos.a has 1GB in size and takes 5 hours to compile
> 
> std.* may include only interfaces, e.g. like in java.sql package. Implementations not necessary in std. Can be third party libraries (e.g. like java JDBC drivers). But standard interfaces give benefits.
So if the std. implementation has a PITA api, all other (probably better approaches) are forced (forced because the user expects an api like this and will probably reject something better but with a different api) to use the same PITA api? This isn't a problem with low-level stuff, but it is something completly different with something as high-level as an ORM. Also an api change in the std. implementation forces *every* 3rd party module to be updated, which is insane, what about a 3 year old implementation which is basically done, everyone considers it stable, now the std. implementation makes a small change, thousands of project will stop working. This isn't a too big problem if the 3 year old implementation is still activly develeoped, but if it isn't ...