Re: UDP enhancement
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
Re: UDP enhancement
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
Re: UDP enhancement
Jacob Carlborg d...@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.
Re: UDP enhancement
On 7/5/13, Jacob Carlborg d...@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.
Re: UDP enhancement
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 Oh hey, I remember the DIP23 madness. Is it that time again already? is to do something like public @property int value; Yes. Please, yes. This kills so much boilerplate. (In fairness, DIP23 was pretty good, aside from the address-of shenanigans and lack of low-hanging operator rewrites.) -Wyatt
Re: UDP enhancement
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 Oh hey, I remember the DIP23 madness. Is it that time again already? is to do something like public @property int value; Yes. Please, yes. This kills so much boilerplate. (In fairness, DIP23 was pretty good, aside from the address-of shenanigans and lack of low-hanging operator rewrites.) -Wyatt DIP24 FTW!
Re: UDP enhancement
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
Re: UDP enhancement
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 the class. 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.
Re: UDP enhancement
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.
Re: UDP enhancement
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
Re: UDP enhancement
Kapps opantm2+s...@gmail.com wrote in message
news:zroaabiwkaxqybrtd...@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.
Re: UDP enhancement
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
Re: UDP enhancement
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
Re: UDP enhancement
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
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.
(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
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.
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
know where
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
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?
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
the class.
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
Re: UDP enhancement
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. 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.
UDP enhancement
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.
Re: UDP enhancement
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
Re: UDP enhancement
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...
Re: UDP enhancement
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; }
}
Re: UDP enhancement
On 7/1/13, JS js.m...@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.
Re: UDP enhancement
On Monday, July 01, 2013 04:03:41 Andrej Mitrovic wrote: On 7/1/13, JS js.m...@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
Re: UDP enhancement
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.
Re: UDP enhancement
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
Re: UDP enhancement
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
@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.
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.
