On Friday, 5 April 2013 at 09:36:04 UTC, Dicebot wrote:
> On Friday, 5 April 2013 at 09:26:30 UTC, Vadim Lopatin wrote:
>> On Friday, 5 April 2013 at 07:57:37 UTC, Dicebot wrote:
>>> On Friday, 5 April 2013 at 07:32:55 UTC, Vadim Lopatin wrote:
>>>> Looks ugly, but I tried `typedef string String`, but it is deprecated; `alias string String` cannot be distinguished from just string. How to define String better? Is there a good way to define String to be compatible with string, but with the ability to distinguish between string and String in compile time?
>>>
>>> Something like this : http://dpaste.1azy.net/ad013e4ef ?
>>
>> It's as I have already implemented it. http://dpaste.1azy.net/a0393ce23
>
> Why do you redefine constructor (it does exactly the same what default one) and prefer getter over raw alias this (thus adding necessity for opAssign)? Other than that looks pretty adequate match to desired behavior.

Thank you!

It was copy+paste from std.typecons Nullable!
Cleaned it up.
Strange thing: this code doesn't work for me if _value is protected - somewhere in CTFE generated code. "_value is unaccessible" It's hard to define exact place where it fails (inside of mixin).
Tried to write different code which uses String with private _value, but cannot reproduce the same error. Leaving public _value so far.

On 2013-04-05 11:22, Vadim Lopatin wrote:
> On Friday, 5 April 2013 at 08:53:56 UTC, Jacob Carlborg wrote:
>> Why won't Nullable!(string) String work?
>
> It's to reduce field size (eliminate unnecessary bool field from
> Nullable!, but it's easy to support both cases.

Aha, I see. I think you can use Nullable!(string, null). Look at the documentation, there's two Nullable:

dlang.org/phobos/std_typecons.html

>> Looks much better know. I'm wondering though, if there need to be a
>> way to indicate a regular instance variable that isn't a column.
>
> 1) Any private, protected, package members are not columns.

Right, didn't think of that. What about methods, can you have a method/property as a column?

> 2) @Transient annotation may be applied to public member to say that it
> shouln't be persisted (like in Java)

Sounds good.

-- 
/Jacob Carlborg

On 2013-04-05 11:44, Vadim Lopatin wrote:

> Submitted fix to support @Transient.
> It can be used on class level as well.
>
> Currently, if module is passed to metadata extractor, only classes which
> have at least one HibernateD annotation are being imported.
> Alternative is to import all classes, skipping only ones marked with
> @Transient.
> Which way is better?

I'm not sure, the current behavior perhaps. I think I would need to try it out do have a proper answer.

-- 
/Jacob Carlborg

On Friday, 5 April 2013 at 12:13:42 UTC, Jacob Carlborg wrote:
>>> Looks much better know. I'm wondering though, if there need to be a
>>> way to indicate a regular instance variable that isn't a column.
>>
>> 1) Any private, protected, package members are not columns.
>
> Right, didn't think of that. What about methods, can you have a method/property as a column?

As addition to fields, two more options supported:
1) Getter/setter pair:
     public T getSomeProperty();
     public xxx setSomeProperty(T value);
   or
     public T isSomeProperty();
     public xxx setSomeProperty(T value);
   treated as property with name 'someProperty'

   Second case is useful for boolean, to sound more natural
   Result type of setter doesn't matter.
   Both getter and setter should be defined, otherwise methods will be ignored.

2) Read/write property
   @property T someProperty() { ... }
   @property xxx someProperty(T value) { ... }
   treated as property with name 'someProperty'

BTW, I don't know how to check if property is read/write in compile time.

On 2013-04-05 16:03, Vadim Lopatin wrote:

> 2) Read/write property
>     @property T someProperty() { ... }
>     @property xxx someProperty(T value) { ... }
>     treated as property with name 'someProperty'
>
> BTW, I don't know how to check if property is read/write in compile time.

If there's no better way you can always use __traits(compiles), something like this:

__traits(compiles, { auto c = new Class; T v = c.someProperty; c.someProperty = T.init; });

Currently that will compile regardless of @property or not.

-- 
/Jacob Carlborg

On Friday, 5 April 2013 at 15:20:06 UTC, Jacob Carlborg wrote:
> On 2013-04-05 16:03, Vadim Lopatin wrote:
>
>> 2) Read/write property
>>    @property T someProperty() { ... }
>>    @property xxx someProperty(T value) { ... }
>>    treated as property with name 'someProperty'
>>
>> BTW, I don't know how to check if property is read/write in compile time.
>
> If there's no better way you can always use __traits(compiles), something like this:
>
> __traits(compiles, { auto c = new Class; T v = c.someProperty; c.someProperty = T.init; });
>
> Currently that will compile regardless of @property or not.

Quoting https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/restutil.d :

template isPropertyGetter(T)
{
	enum isPropertyGetter = (functionAttributes!(T) & FunctionAttribute.property) != 0
		&& !is(ReturnType!T == void);
}

template isPropertySetter(T)
{
	enum isPropertySetter = (functionAttributes!(T) & FunctionAttribute.property) != 0
		&& is(ReturnType!T == void);
}

On Friday, 5 April 2013 at 15:52:43 UTC, Dicebot wrote:
> On Friday, 5 April 2013 at 15:20:06 UTC, Jacob Carlborg wrote:
>> On 2013-04-05 16:03, Vadim Lopatin wrote:
>>
>>> 2) Read/write property
>>>   @property T someProperty() { ... }
>>>   @property xxx someProperty(T value) { ... }
>>>   treated as property with name 'someProperty'
>>>
>>> BTW, I don't know how to check if property is read/write in compile time.
>>
>> If there's no better way you can always use __traits(compiles), something like this:
>>
>> __traits(compiles, { auto c = new Class; T v = c.someProperty; c.someProperty = T.init; });
>>
>> Currently that will compile regardless of @property or not.
>
> Quoting https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/restutil.d :
>
> template isPropertyGetter(T)
> {
> 	enum isPropertyGetter = (functionAttributes!(T) & FunctionAttribute.property) != 0
> 		&& !is(ReturnType!T == void);
> }
>
> template isPropertySetter(T)
> {
> 	enum isPropertySetter = (functionAttributes!(T) & FunctionAttribute.property) != 0
> 		&& is(ReturnType!T == void);
> }

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?

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) ) {
---

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) ) {
> ---

Thanks a lot! It looks like Vibe is a good source :)

On Wed, 03 Apr 2013 20:01:54 +0200
"Vadim Lopatin" <coolreader.org@gmail.com> wrote:
> 
> Besides connection replacement, I've added some getters to retrieve resultset and parameters metadata from mysqln, to support NULL blobs, and some more fixes.

I fixed the NULL blob thing in the main mysql-native's master a few weeks ago. I'll take a look at the rest.

On Thu, 04 Apr 2013 00:50:39 +0200
"Robert" <jfanatiker@gmx.at> wrote:
>
> :-S The better way would be to just depend on a Stream interface and switch implementations by instantiating different classes. -> The used Stream interface would of course need to be factored out of vibe, ideally into the standard library.
> 
> This would be way more flexible: Users of the library can use either implementation without even having to recompile the library. No additional runtime cost either.
> 

That would indeed be more flexible, but I'm not sure I can imagine a reason to ever use anything besides phobos connections and vibe.d connections (but maybe I'm wrong?). Plus, hopefully phobos connections will eventually gain the ability to work like vibe.d connections and obviate the need for vibe.d to have it's own connections. So I'm not sure whether it would really be worth it.

> "-version" should not be used too liberally in my opinion, because it is really inflexible, especially when it comes to binary/shared libraries.
> 

I wasn't talking about using -version to switch between implementations. Just to disable the dependency on vibe.d (which of course would also disable the *option* of using vibe.d connections).