www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UDP enhancement

reply "JS" <js.mdnq gmail.com> writes:
struct Foo
{
      property int data() { return m_data; } // read property
      property int data(int value) { return m_data = value; } // 
write property
     private: int m_data;
}

It would be nice if properties had an internal variable to use 
instead of having to declare it explicitly:


struct Foo
{
      property int data() { return data.value; } // read property
      property int data(int value) { return data.value; } // write 
property
}

This reduces code complexity. If a property does not use the 
internal variable(which I signify by .value) then it does not add 
any storage. This allows one to easily wrap fields into 
properties without having to create private fields for each 
property unless needed.
Jun 30 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, July 01, 2013 03:22:15 JS wrote:
 struct Foo
 {
       property int data() { return m_data; } // read property
       property int data(int value) { return m_data = value; } //
 write property
      private: int m_data;
 }
 
 It would be nice if properties had an internal variable to use
 instead of having to declare it explicitly:
 
 
 struct Foo
 {
       property int data() { return data.value; } // read property
       property int data(int value) { return data.value; } // write
 property
 }
 
 This reduces code complexity. If a property does not use the
 internal variable(which I signify by .value) then it does not add
 any storage. This allows one to easily wrap fields into
 properties without having to create private fields for each
 property unless needed.

I believe that the way that this sort of enhancement has typically been suggested is to do something like public property int value; which would be lowered to something like public property int value() safe const pure nothrow { return _value; } public property int value(int v) safe pure nothrow { return _value = v; } private int _value; And I think that that's clearer than your suggestion (it's definitely shorter). It also doesn't require the compiler to infer anything about whether you meant to have it create a variable or not. It simply tells the compiler what to do in a more concise manner. - Jonathan M Davis
Jun 30 2013
next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 01.07.2013 03:35, Jonathan M Davis pisze:
 On Monday, July 01, 2013 03:22:15 JS wrote:
 struct Foo
 {
        property int data() { return m_data; } // read property
        property int data(int value) { return m_data = value; } //
 write property
       private: int m_data;
 }

 It would be nice if properties had an internal variable to use
 instead of having to declare it explicitly:


 struct Foo
 {
        property int data() { return data.value; } // read property
        property int data(int value) { return data.value; } // write
 property
 }

 This reduces code complexity. If a property does not use the
 internal variable(which I signify by .value) then it does not add
 any storage. This allows one to easily wrap fields into
 properties without having to create private fields for each
 property unless needed.

I believe that the way that this sort of enhancement has typically been suggested is to do something like public property int value; which would be lowered to something like public property int value() safe const pure nothrow { return _value; } public property int value(int v) safe pure nothrow { return _value = v; } private int _value;

This is nice, and this pattern promotes overriding of properties.
 And I think that that's clearer than your suggestion (it's definitely shorter).
 It also doesn't require the compiler to infer anything about whether you meant
 to have it create a variable or not. It simply tells the compiler what to do
 in a more concise manner.

Yes, it's clearer and more importantly it doesn't hide aggregate fields inside methods. Data layout of an aggregate should be clear IMHO.
Jun 30 2013
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/30/2013 06:43 PM, JS wrote:

 On Monday, July 01, 2013 03:22:15 JS wrote:
 struct Foo
 {
       property int data() { return m_data; } // read property
       property int data(int value) { return m_data = value; } //
 write property
      private: int m_data;
 }

 It would be nice if properties had an internal variable to use
 instead of having to declare it explicitly:


 struct Foo
 {
       property int data() { return data.value; } // read property
       property int data(int value) { return data.value; } // write
 property
 }

 This reduces code complexity.



I have the complete opposite view: Seeing what m_data explicitly in the code would be simpler than reading code to see that data.value would mean implicit storage.
 (if propertyname.value is used then
 there needs to be an internal variable, else not),

Where would the compiler make room for that variable in relation to the other members? With programming languages, explicit is almost always better than implicit. Ali
Jun 30 2013
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/30/2013 08:54 PM, JS wrote:

 On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:

 I have the complete opposite view: Seeing what m_data explicitly in
 the code would be simpler than reading code to see that data.value
 would mean implicit storage.

huh? There is absolutely no semantic difference between the two.

Agreed. I find implicit storage making code more complex.
 The
 proposed case is easier because the field can't be hidden away somewhere
 making it hard to find.

  property T x() { }

 represents a function and possibly a variable of type T. You know that
 by looking at the property. It is not a hard leap to understand.

Agreed but I was talking about understanding the implementation, not the API. When a function returns data.value, it returns the 'value' member of a variable 'data'. Where is 'data'? Not a local variable. Not a member? A global? Oh! I wonder? Yes, it is an implicit member that is created by the compiler. Note the old proposal that Jonathan has reminded us about does not have that problem. It is obvious that we are looking at a property.
 The old way:

  property T x() { }
 T _x;

 Is more verbose, and verbose is not always better.

Agreed in general but not in this case.
 If your class as many
 variables and some are hidden then it could be difficult to know where
 the variable is.

That is always possible and requires discipline and coding guidelines. The programmers must know to communicate ideas and designs.
 It's no different than writing separate setters and getters... no
 difference... just they are more verbose. If you are against my
 suggestion you should be against properties in general because they are
 a simplification of such.

I am not against how they make syntax easier. I don't need to prefix function names by get_ or set_ and I don't need to use parentheses.
 (if propertyname.value is used then
 there needs to be an internal variable, else not),

Where would the compiler make room for that variable in relation to the other members? With programming languages, explicit is almost always better than implicit. Ali

huh? The exact same place it does so if the programmer explicitly adds it.

How can the compiler put it in *the exact spot* if I am not adding it explicitly? Are you suggesting that such functions be inserted between other member variables? struct Foo { int m; property int data() { return data.value; } // read property property int data(int value) { return data.value; } // write property double d; } What if there is another member between these special functions? Compiler error?
 It's location in the class my not be the same but that is, in
 general, irrelevant unless you are messing with the bits of the class.

I was thinking about structs. Ali
Jul 01 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-07-01 03:43, JS wrote:

 But yet absolutely useless and does nothing over using a field directly.

The advantage is that you get virtual methods. I also think it should be possible to manually implement just the setter, or getter. The compiler would only generate what's not already present. -- /Jacob Carlborg
Jul 01 2013
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Kapps" <opantm2+spam gmail.com> wrote in message 
news:zroaabiwkaxqybrtdhxp forum.dlang.org...
 As someone who uses properties almost everywhere, and almost never uses 
 public fields, this is one of my biggest gripes with D remaining. It's 
 incredibly annoying to have to do things like

 private int _width;
 /// Gets or sets the total width, in pixels, of this control.
  property int width() const {
     return _width;
 }
 /// ditto
  property void width(int value) {
     this._width = value;
 }


 Something like

 /// Gets or sets the total width, in pixels, of this control.
  property const int width;

 Is just so much nicer and saves so much bloat. I feel like the current 
 property syntax is one of those places where IDE code snippets will start 
 to become, not necessary, but extremely useful. It's the type of manual 
 repetition that D aims to avoid, but in this case fails at.
 I don't know if I agree with automatically expanding to const though. I'd 
 like to be able to do ' property Control parent' without needing to return 
 a const(Control) because the property is expanded to be const. Although if 
 we had a virtual keyword, final is something that I think should be 
 default for properties, and I think it's a mistake that the current 
  property doesn't infer final in the first place. Safe and nothrow are two 
 assumptions that are probably quite safe to assume for the most part as 
 well.

You should probably try using template mixins, if all you need to do is expand some code.
Jul 02 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-07-03 03:42, Daniel Murphy wrote:

 You should probably try using template mixins, if all you need to do is
 expand some code.

I don't think that works so well together with ddoc comments. Ideally you should be able to do something like this: class Foo { /// Get/set bar mixin property!(int, "bar"); } -- /Jacob Carlborg
Jul 05 2013
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:kr673g$179s$1 digitalmars.com...
 On 2013-07-03 03:42, Daniel Murphy wrote:

 You should probably try using template mixins, if all you need to do is
 expand some code.

I don't think that works so well together with ddoc comments. Ideally you should be able to do something like this: class Foo { /// Get/set bar mixin property!(int, "bar"); } -- /Jacob Carlborg

True, for now.
Jul 05 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-07-05 14:31, Andrej Mitrovic wrote:

 Related: https://github.com/D-Programming-Language/dmd/pull/1485

 Although this pull does the opposite of what's requested here.

In this case I don't think you want to show the methods the mixin expands to. -- /Jacob Carlborg
Jul 06 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/05/2013 03:53 PM, Wyatt wrote:
 On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
 I believe that the way that this sort of enhancement has typically
 been suggested

 is to do something like

 public  property int value;

(In fairness, DIP23 was pretty good, aside from the address-of shenanigans and lack of low-hanging operator rewrites.) -Wyatt

DIP24 FTW!
Jul 05 2013
prev sibling next sibling parent "JS" <js.mdnq gmail.com> writes:
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
 On Monday, July 01, 2013 03:22:15 JS wrote:
 struct Foo
 {
       property int data() { return m_data; } // read property
       property int data(int value) { return m_data = value; } 
 //
 write property
      private: int m_data;
 }
 
 It would be nice if properties had an internal variable to use
 instead of having to declare it explicitly:
 
 
 struct Foo
 {
       property int data() { return data.value; } // read 
 property
       property int data(int value) { return data.value; } // 
 write
 property
 }
 
 This reduces code complexity. If a property does not use the
 internal variable(which I signify by .value) then it does not 
 add
 any storage. This allows one to easily wrap fields into
 properties without having to create private fields for each
 property unless needed.

I believe that the way that this sort of enhancement has typically been suggested is to do something like public property int value; which would be lowered to something like public property int value() safe const pure nothrow { return _value; } public property int value(int v) safe pure nothrow { return _value = v; } private int _value; And I think that that's clearer than your suggestion (it's definitely shorter). It also doesn't require the compiler to infer anything about whether you meant to have it create a variable or not. It simply tells the compiler what to do in a more concise manner. - Jonathan M Davis

But yet absolutely useless and does nothing over using a field directly. If you are worried about the compiler not being able to infer if an internal variable needs to be used or not(which is kinda ridiculous because it is very simple to do so(if propertyname.value is used then there needs to be an internal variable, else not), one can just use a new keyword/attribute propertyval or something...
Jun 30 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/01/2013 03:22 AM, JS wrote:
 struct Foo
 {
       property int data() { return m_data; } // read property
       property int data(int value) { return m_data = value; } // write
 property
      private: int m_data;
 }

 It would be nice if properties had an internal variable to use instead
 of having to declare it explicitly:


 struct Foo
 {
       property int data() { return data.value; } // read property
       property int data(int value) { return data.value; } // write property
 }

 This reduces code complexity. If a property does not use the internal
 variable(which I signify by .value) then it does not add any storage.
 This allows one to easily wrap fields into properties without having to
 create private fields for each property unless needed.

struct S{ T value; } struct T{ S get(){ return S(this); } alias get this; } struct Foo{ property S data(){ return data.value; } }
Jun 30 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 7/1/13, JS <js.mdnq gmail.com> wrote:
 But yet absolutely useless and does nothing over using a field
 directly.

Not completely useless, this syntax would theoretically disallow taking the address of such a field.
Jun 30 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, July 01, 2013 04:03:41 Andrej Mitrovic wrote:
 On 7/1/13, JS <js.mdnq gmail.com> wrote:
 But yet absolutely useless and does nothing over using a field
 directly.

Not completely useless, this syntax would theoretically disallow taking the address of such a field.

Yeah. public fields and property functions are _not_ interchangeable, much as we'd like them to be. By going with what I suggested, you get the short syntax of declaring a variable, but you end up with actual functions so that you don't have issues with later swapping the field out with property functions that you write yourself when you decide that you need them to do more. - Jonathan M Davis
Jun 30 2013
prev sibling next sibling parent "JS" <js.mdnq gmail.com> writes:
On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:
 On 06/30/2013 06:43 PM, JS wrote:

 On Monday, July 01, 2013 03:22:15 JS wrote:
 struct Foo
 {
       property int data() { return m_data; } // read



       property int data(int value) { return m_data = value;



 write property
      private: int m_data;
 }

 It would be nice if properties had an internal variable to



 instead of having to declare it explicitly:


 struct Foo
 {
       property int data() { return data.value; } // read



       property int data(int value) { return data.value; }



 property
 }

 This reduces code complexity.



I have the complete opposite view: Seeing what m_data explicitly in the code would be simpler than reading code to see that data.value would mean implicit storage.

huh? There is absolutely no semantic difference between the two. The proposed case is easier because the field can't be hidden away somewhere making it hard to find. property T x() { } represents a function and possibly a variable of type T. You know that by looking at the property. It is not a hard leap to understand. The old way: property T x() { } T _x; Is more verbose, and verbose is not always better. If your class as many variables and some are hidden then it could be difficult to know where the variable is. If the field is not of the same type then either the original method can be used or possibly an extension: property T:W x() { return x.value.t; } represents the same as property T x() { return _x.t; } W _x; There is absolutely no difference in semantics... just syntax. One is more verbose. It shouldn't be difficult to see that. It's no different than writing separate setters and getters... no difference... just they are more verbose. If you are against my suggestion you should be against properties in general because they are a simplification of such.
 (if propertyname.value is used then
 there needs to be an internal variable, else not),

Where would the compiler make room for that variable in relation to the other members? With programming languages, explicit is almost always better than implicit. Ali

huh? The exact same place it does so if the programmer explicitly adds it. It's location in the class my not be the same but that is, in general, irrelevant unless you are messing with the bits of the class.
Jun 30 2013
prev sibling next sibling parent "JS" <js.mdnq gmail.com> writes:
On Monday, 1 July 2013 at 16:24:40 UTC, Ali Çehreli wrote:
 On 06/30/2013 08:54 PM, JS wrote:

 On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:

 I have the complete opposite view: Seeing what m_data


 the code would be simpler than reading code to see that


 would mean implicit storage.

huh? There is absolutely no semantic difference between the

Agreed. I find implicit storage making code more complex.

(Well, I'm sure some will find it useful in some cases and I don't think such a case could hurt much but I'd probably never use it)
 The
 proposed case is easier because the field can't be hidden

 making it hard to find.

  property T x() { }

 represents a function and possibly a variable of type T. You

 by looking at the property. It is not a hard leap to

Agreed but I was talking about understanding the implementation, not the API. When a function returns data.value, it returns the 'value' member of a variable 'data'. Where is 'data'? Not a local variable. Not a member? A global? Oh! I wonder? Yes, it is an implicit member that is created by the compiler. Note the old proposal that Jonathan has reminded us about does not have that problem. It is obvious that we are looking at a property.

Well, I personally don't care what symbols or syntax you want to use(well, within reason). I used a common syntax because it is something people are familiar with. To me it is nitpicking because it has nothing to do with the real issue. It's not the syntax that is under question but the concept/implementation. What's important to me is to not have to create a private field every time I want to create a property. It seems like a waste of time and is verbose for no reason. It doesn't confuse me one bit to "hide" the field in the property because essentially that's what properties do(to the user of the property)... So it doesn't change anything from the outside and only goes to reduce your code size.
 The old way:

  property T x() { }
 T _x;

 Is more verbose, and verbose is not always better.

Agreed in general but not in this case.
 If your class as many
 variables and some are hidden then it could be difficult to

 the variable is.

That is always possible and requires discipline and coding guidelines. The programmers must know to communicate ideas and designs.

Yes, but any programming language is there to simplify... If we had infinite memories and intelligence then direct machine language(hex) would be just fine. IMO by removing excess and essentially useless text in source code makes it easier to follow and maintain. Almost all programming constructs do this... sometimes it's their sole purpose(a macro, function, struct, etc...). (encapsulation of data/code is mainly to simplify complexity and not for security/safety)
 It's no different than writing separate setters and

 difference... just they are more verbose. If you are against

 suggestion you should be against properties in general

 a simplification of such.

I am not against how they make syntax easier. I don't need to prefix function names by get_ or set_ and I don't need to use parentheses.
 (if propertyname.value is used then
 there needs to be an internal variable, else not),

Where would the compiler make room for that variable in


 the other members? With programming languages, explicit is


 always better than implicit.

 Ali

huh? The exact same place it does so if the programmer

 it.

How can the compiler put it in *the exact spot* if I am not adding it explicitly? Are you suggesting that such functions be inserted between other member variables?

I'm not sure we are are talking about the same thing:
 struct Foo
 {
     int m;
      property int data() { return data.value; } // read property
      property int data(int value) { return data.value; } // 
 write property
     double d;
 }

 What if there is another member between these special 
 functions? Compiler error?

 It's location in the class my not be the same but that is, in
 general, irrelevant unless you are messing with the bits of

I was thinking about structs. Ali

struct Foo { // int data.value; "inserted here" int m; // int data.value; or here property int data() { return data.value; } // read property // int data.value; or here property int data(int value) { return data.value = value; } // write property // int data.value; or here double d; // int data.value; or here } vs struct Foo { int m; property int data() { return val; } // read property property int data(int value) { return val = value; } // write property double d; private int val; } It will almost never matter where the compiler inserts the hidden variable for us except when "hacking" the struct(which, as long as it's consistent, it shouldn't matter. to me, the first case is more concise but does EXACTLY the same thing. I like things to be concise. I don't wanna see crap that I don't need to see. In the 2nd case, val is only required because the compiler is not smart enough. We can easily write a preprocessor to do the above(in fact, I've done it before).
Jul 01 2013
prev sibling next sibling parent "estew" <estewh gmail.com> writes:
 It's location in the class my not be the same but that is, in
 general, irrelevant unless you are messing with the bits of



Actually we do this a lot in C++ where I work to ensure proper alignment. We are also starting to do this in D where we have C++ <-> D bindings so we can make our D structs exactly match our C++ structs in memory. Personally I see less benefit over: public property int value; This approach is nice. It can be used both when layout is important and when it is "don't care" and is clearer. I can look at the struct and immediately read its memory footprint. Your suggested proposal cannot be used when layout is important as it is left to the compiler. It would require a workaround to coerce the compiler into submission, or additional compiler circuitry making it even more complex and slowing it down.
Jul 01 2013
prev sibling next sibling parent "JS" <js.mdnq gmail.com> writes:
On Tuesday, 2 July 2013 at 04:49:55 UTC, estew wrote:
 It's location in the class my not be the same but that is, 
 in
 general, irrelevant unless you are messing with the bits of



Actually we do this a lot in C++ where I work to ensure proper alignment. We are also starting to do this in D where we have C++ <-> D bindings so we can make our D structs exactly match our C++ structs in memory. Personally I see less benefit over: public property int value; This approach is nice. It can be used both when layout is important and when it is "don't care" and is clearer. I can look at the struct and immediately read its memory footprint. Your suggested proposal cannot be used when layout is important as it is left to the compiler. It would require a workaround to coerce the compiler into submission, or additional compiler circuitry making it even more complex and slowing it down.

Or just use the old way. Just because one extends a feature does not mean the old feature is removed. If you need to hack up the bits just explicitly allocate the field... simple as that.
Jul 02 2013
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
 I believe that the way that this sort of enhancement has 
 typically been
 suggested is to do something like

 public  property int value;

 which would be lowered to something like

 public  property int value()  safe const pure nothrow { return 
 _value; }
 public  property int value(int v)  safe pure nothrow { return 
 _value = v; }
 private int _value;

 - Jonathan M Davis

As someone who uses properties almost everywhere, and almost never uses public fields, this is one of my biggest gripes with D remaining. It's incredibly annoying to have to do things like private int _width; /// Gets or sets the total width, in pixels, of this control. property int width() const { return _width; } /// ditto property void width(int value) { this._width = value; } Something like /// Gets or sets the total width, in pixels, of this control. property const int width; Is just so much nicer and saves so much bloat. I feel like the current property syntax is one of those places where IDE code snippets will start to become, not necessary, but extremely useful. It's the type of manual repetition that D aims to avoid, but in this case fails at. I don't know if I agree with automatically expanding to const though. I'd like to be able to do ' property Control parent' without needing to return a const(Control) because the property is expanded to be const. Although if we had a virtual keyword, final is something that I think should be default for properties, and I think it's a mistake that the current property doesn't infer final in the first place. Safe and nothrow are two assumptions that are probably quite safe to assume for the most part as well.
Jul 02 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, July 02, 2013 19:49:39 Kapps wrote:
 On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
 I believe that the way that this sort of enhancement has
 typically been
 suggested is to do something like
 
 public  property int value;
 
 which would be lowered to something like
 
 public  property int value()  safe const pure nothrow { return
 _value; }
 public  property int value(int v)  safe pure nothrow { return
 _value = v; }
 private int _value;
 
 - Jonathan M Davis

As someone who uses properties almost everywhere, and almost never uses public fields, this is one of my biggest gripes with D remaining. It's incredibly annoying to have to do things like private int _width; /// Gets or sets the total width, in pixels, of this control. property int width() const { return _width; } /// ditto property void width(int value) { this._width = value; } Something like /// Gets or sets the total width, in pixels, of this control. property const int width; Is just so much nicer and saves so much bloat. I feel like the current property syntax is one of those places where IDE code snippets will start to become, not necessary, but extremely useful. It's the type of manual repetition that D aims to avoid, but in this case fails at. I don't know if I agree with automatically expanding to const though.

inout would probably be better then. But without that, anyone wanting to be const-correct is going to have to declare all of the getters themselves. inout isn't quite there, because there are many cases where you really do want to return const even when the object is mutable, but it would probably be a good compromise. - Jonathan M Davis
Jul 02 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 7/5/13, Jacob Carlborg <doob me.com> wrote:
 I don't think that works so well together with ddoc comments. Ideally
 you should be able to do something like this:

 class Foo
 {
      /// Get/set bar
      mixin property!(int, "bar");
 }

Related: https://github.com/D-Programming-Language/dmd/pull/1485 Although this pull does the opposite of what's requested here.
Jul 05 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
 I believe that the way that this sort of enhancement has 
 typically been suggested

already?
 is to do something like

 public  property int value;

(In fairness, DIP23 was pretty good, aside from the address-of shenanigans and lack of low-hanging operator rewrites.) -Wyatt
Jul 05 2013
prev sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 3 July 2013 at 01:42:06 UTC, Daniel Murphy wrote:
 You should probably try using template mixins, if all you need 
 to do is
 expand some code.

https://github.com/D-Programming-Language/phobos/pull/1294
Jul 05 2013