Re: Getters/setters generator
On Tuesday, 13 June 2017 at 21:49:53 UTC, jmh530 wrote:
On Tuesday, 13 June 2017 at 20:45:34 UTC, jmh530 wrote:
Fair point. I just was playing around with it today and was
like, oh that's pretty easy. It was only when I was trying to
see if anyone else had done anything like this that I came
across your project.
I was just looking at the code in the package. There was an
earlier discussion on predicates. If you changed the
Read/RefRead/etc structs to be something like below, then the
user could add in a string of the assert. It's not really all
that elegant, but I think you should be able to get it to work.
struct Read
{
string visibility = "public";
string constraint = void;
}
My ideal was to get something working where the lower and upper
bounds were actual values, so you didn't have to pass the
string, but I can see how that gets complicated. One problem I
ran into is that you can't really make a struct templated in an
optional way. For instance, the following won't compile
(ignoring the complexity of making the asserts > or >=):
struct Read(T = void)
{
string visibility = "public";
static if (!is(T == void)) {
T lower;
T upper;
}
}
void main()
{
Read read;
}
I think that predicates aren't predicates for specific types
(like lower/upper for arithmetic types), but generic predicates
that could replace in/out constraints. For example lower/upper
boundaries could be expressed then as "x >= a && x < b".
Now it isn't clear what should happen if the predicate doesn't
hold (do we use enforce and throw an exception or assert and
throw an error). Ok, it can be solved with template parameter for
the GenerateFieldAccessors mixin).
String constraints are imho ugly and error prone. For example I
personally don't use alogrithms like sort with string predicates,
but only with lambdas.
Maybe it is possible to pass a lambda to the struct that gets a
value of the member and evaluetes to a boolean - I haven't tested
it. But even with a lambda it doesn't look that cool:
@ConstRead @Write(ref x => x > 0 && x < 10)
Re: Getters/setters generator
On Tuesday, 13 June 2017 at 20:45:34 UTC, jmh530 wrote:
Fair point. I just was playing around with it today and was
like, oh that's pretty easy. It was only when I was trying to
see if anyone else had done anything like this that I came
across your project.
I was just looking at the code in the package. There was an
earlier discussion on predicates. If you changed the
Read/RefRead/etc structs to be something like below, then the
user could add in a string of the assert. It's not really all
that elegant, but I think you should be able to get it to work.
struct Read
{
string visibility = "public";
string constraint = void;
}
My ideal was to get something working where the lower and upper
bounds were actual values, so you didn't have to pass the string,
but I can see how that gets complicated. One problem I ran into
is that you can't really make a struct templated in an optional
way. For instance, the following won't compile (ignoring the
complexity of making the asserts > or >=):
struct Read(T = void)
{
string visibility = "public";
static if (!is(T == void)) {
T lower;
T upper;
}
}
void main()
{
Read read;
}
Re: Getters/setters generator
On Tuesday, 13 June 2017 at 20:31:25 UTC, Eugene Wissner wrote: I suppose the errors will be more cryptic, since you don't check if the string referers to an existing member. You provide only get/set that return by value. So you may need to generate getters/setters for const values, for ref values, for const ref values... And it would result in much more code for every object. Fair point. I just was playing around with it today and was like, oh that's pretty easy. It was only when I was trying to see if anyone else had done anything like this that I came across your project.
Re: Getters/setters generator
On Tuesday, 13 June 2017 at 19:31:28 UTC, jmh530 wrote:
On Sunday, 11 December 2016 at 02:17:18 UTC, Mike Parker wrote:
What are properties if not "getters" and "setters"? From the
original post: "It would generate 2 methods "num": one to set
num_ and one to get its value."
Two methods named "num". No "get" or "set" in sight.
Sorry to bump, but it also isn't hard to use mixins to write
more generic get/set.
import std.stdio : writeln;
struct Foo
{
private int a;
private int b;
void set(string variable)(int x) @property
{
mixin(variable ~ " = x;");
}
int get(string variable)() @property
{
return mixin(variable);
}
}
void main()
{
Foo foo;
foo.set!("a")(1);
foo.set!("b")(2);
writeln(foo.get!("a"));
writeln(foo.get!("b"));
}
I suppose the errors will be more cryptic, since you don't check
if the string referers to an existing member.
You provide only get/set that return by value. So you may need to
generate getters/setters for const values, for ref values, for
const ref values... And it would result in much more code for
every object.
Re: Getters/setters generator
On Sunday, 11 December 2016 at 02:17:18 UTC, Mike Parker wrote:
What are properties if not "getters" and "setters"? From the
original post: "It would generate 2 methods "num": one to set
num_ and one to get its value."
Two methods named "num". No "get" or "set" in sight.
Sorry to bump, but it also isn't hard to use mixins to write more
generic get/set.
import std.stdio : writeln;
struct Foo
{
private int a;
private int b;
void set(string variable)(int x) @property
{
mixin(variable ~ " = x;");
}
int get(string variable)() @property
{
return mixin(variable);
}
}
void main()
{
Foo foo;
foo.set!("a")(1);
foo.set!("b")(2);
writeln(foo.get!("a"));
writeln(foo.get!("b"));
}
Re: Getters/setters generator
On Wednesday, 18 January 2017 at 21:57:42 UTC, Andrei Alexandrescu wrote: On 1/18/17 5:29 PM, Mark wrote: I see. Is there a way to call invariant() of a class/struct directly? That would obviate the need for a particular predicate (copy the class state, run the setter, check if invariants are satisfied and restore previous state if they aren't). It seems painfully obvious the right way is a guarded assignment and anything else would be a more or less painful workaround. -- Andrei I agree. I'm just a bit unsettled by the slight code duplication that would ensue.
Re: Getters/setters generator
On 1/18/17 5:29 PM, Mark wrote: I see. Is there a way to call invariant() of a class/struct directly? That would obviate the need for a particular predicate (copy the class state, run the setter, check if invariants are satisfied and restore previous state if they aren't). It seems painfully obvious the right way is a guarded assignment and anything else would be a more or less painful workaround. -- Andrei
Re: Getters/setters generator
On Wednesday, 18 January 2017 at 15:29:43 UTC, Mark wrote: On Tuesday, 17 January 2017 at 15:59:26 UTC, Andrei Alexandrescu wrote: On 1/17/17 12:08 PM, Mark wrote: On Tuesday, 17 January 2017 at 09:17:56 UTC, Andrei Alexandrescu wrote: [...] Given that D supports class invariants, is there a real need for predicated setters? The invariant is evaluated after the setter has taken place, i.e. after the object has been corrupted. The setter guard prevents corruption from happening. -- Andrei I see. Is there a way to call invariant() of a class/struct directly? That would obviate the need for a particular predicate (copy the class state, run the setter, check if invariants are satisfied and restore previous state if they aren't). You can call invariant directly with `assert(this);` IIRC.
Re: Getters/setters generator
On Tuesday, 17 January 2017 at 15:59:26 UTC, Andrei Alexandrescu wrote: On 1/17/17 12:08 PM, Mark wrote: On Tuesday, 17 January 2017 at 09:17:56 UTC, Andrei Alexandrescu wrote: On 1/17/17 9:32 AM, Eugene Wissner wrote: Ah, well thanks. I don't think it makes much sense since it would be easier to write a complete setter if the user needs extra checks. Accessors are there only for the generation of the standard methods, that just get or set some object property. Hmmm... that's a bit of a bummer because it helps only the degenerate case (accessors are there as placeholders for future extensions, and otherwise offer no protection whatsoever compared to a public value). The question would be then what would be use cases for the accessors. Predicated setters are not just a random thing one might want out of many possibilities, it's a frequent pattern. -- Andrei Given that D supports class invariants, is there a real need for predicated setters? The invariant is evaluated after the setter has taken place, i.e. after the object has been corrupted. The setter guard prevents corruption from happening. -- Andrei I see. Is there a way to call invariant() of a class/struct directly? That would obviate the need for a particular predicate (copy the class state, run the setter, check if invariants are satisfied and restore previous state if they aren't).
Re: Getters/setters generator
On 1/17/17 12:08 PM, Mark wrote: On Tuesday, 17 January 2017 at 09:17:56 UTC, Andrei Alexandrescu wrote: On 1/17/17 9:32 AM, Eugene Wissner wrote: Ah, well thanks. I don't think it makes much sense since it would be easier to write a complete setter if the user needs extra checks. Accessors are there only for the generation of the standard methods, that just get or set some object property. Hmmm... that's a bit of a bummer because it helps only the degenerate case (accessors are there as placeholders for future extensions, and otherwise offer no protection whatsoever compared to a public value). The question would be then what would be use cases for the accessors. Predicated setters are not just a random thing one might want out of many possibilities, it's a frequent pattern. -- Andrei Given that D supports class invariants, is there a real need for predicated setters? The invariant is evaluated after the setter has taken place, i.e. after the object has been corrupted. The setter guard prevents corruption from happening. -- Andrei
Re: Getters/setters generator
On Tuesday, 17 January 2017 at 09:17:56 UTC, Andrei Alexandrescu wrote: On 1/17/17 9:32 AM, Eugene Wissner wrote: Ah, well thanks. I don't think it makes much sense since it would be easier to write a complete setter if the user needs extra checks. Accessors are there only for the generation of the standard methods, that just get or set some object property. Hmmm... that's a bit of a bummer because it helps only the degenerate case (accessors are there as placeholders for future extensions, and otherwise offer no protection whatsoever compared to a public value). The question would be then what would be use cases for the accessors. Predicated setters are not just a random thing one might want out of many possibilities, it's a frequent pattern. -- Andrei Given that D supports class invariants, is there a real need for predicated setters?
Re: Getters/setters generator
On 1/17/17 9:32 AM, Eugene Wissner wrote: Ah, well thanks. I don't think it makes much sense since it would be easier to write a complete setter if the user needs extra checks. Accessors are there only for the generation of the standard methods, that just get or set some object property. Hmmm... that's a bit of a bummer because it helps only the degenerate case (accessors are there as placeholders for future extensions, and otherwise offer no protection whatsoever compared to a public value). The question would be then what would be use cases for the accessors. Predicated setters are not just a random thing one might want out of many possibilities, it's a frequent pattern. -- Andrei
Re: Getters/setters generator
On 1/17/17 8:26 AM, Eugene Wissner wrote: On Friday, 9 December 2016 at 18:53:55 UTC, Andrei Alexandrescu wrote: Love it, and was toying with similar ideas too. One good extension is to add a predicate to the setter, which guards the assignment. -- Andrei What kind of predicate do you mean? Can you give an example please? Say you have a property "percent". The setter should do an enforce(value >= 0 && value <= 100) before the assignment. -- Andrei
Re: Getters/setters generator
On Tuesday, 17 January 2017 at 07:06:05 UTC, Stefan Koch wrote:
On Tuesday, 17 January 2017 at 06:26:35 UTC, Eugene Wissner
wrote:
On Friday, 9 December 2016 at 18:53:55 UTC, Andrei
Alexandrescu wrote:
Love it, and was toying with similar ideas too. One good
extension is to add a predicate to the setter, which guards
the assignment. -- Andrei
What kind of predicate do you mean? Can you give an example
please?
setValue(uint _under24)
{
assert(_under24 < 24);
under24 = _under24;
}
Ah, well thanks. I don't think it makes much sense since it would
be easier to write a complete setter if the user needs extra
checks. Accessors are there only for the generation of the
standard methods, that just get or set some object property.
Re: Getters/setters generator
On Tuesday, 17 January 2017 at 06:26:35 UTC, Eugene Wissner wrote:
On Friday, 9 December 2016 at 18:53:55 UTC, Andrei Alexandrescu
wrote:
Love it, and was toying with similar ideas too. One good
extension is to add a predicate to the setter, which guards
the assignment. -- Andrei
What kind of predicate do you mean? Can you give an example
please?
setValue(uint _under24)
{
assert(_under24 < 24);
under24 = _under24;
}
Re: Getters/setters generator
On Friday, 9 December 2016 at 18:53:55 UTC, Andrei Alexandrescu wrote: Love it, and was toying with similar ideas too. One good extension is to add a predicate to the setter, which guards the assignment. -- Andrei What kind of predicate do you mean? Can you give an example please?
Re: Getters/setters generator
On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote:
Hello,
we've just open sourced a small module ("accessors") that helps
to generate getters and setters automatically:
https://github.com/funkwerk/accessors
http://code.dlang.org/packages/accessors
It takes advantage of the UDAs and mixins. A simple example
would be:
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
mixin(GenerateFieldAccessors);
}
It would generate 2 methods "num": one to set num_ and one to
get its value. Of cause you can generate only @Read without
@Write and vice versa. There are some more features, you can
find the full documentation in the README.
"GenerateFieldAccessors" mixin should be added into each
class/struct that wants to use auto generated accessors.
We just released the next version of the accessors: v1.1.0
- One problem with inheritance was fixed.
- And the generated accessors are always properties know.
Re: Getters/setters generator
On Sunday, 11 December 2016 at 03:15:55 UTC, Mike Bierlee wrote: I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters. Here is the pull request to add @property to the generated methods: https://github.com/funkwerk/accessors/pull/4
Re: Getters/setters generator
On Sunday, 11 December 2016 at 06:55:22 UTC, Mike Parker wrote: On Sunday, 11 December 2016 at 03:15:55 UTC, Mike Bierlee wrote: I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters. Right, any no-arg function can be called without parentheses, and single-arg functions can be called as 'func = foo'. At this point, I don't think think @property is ever going to be fixed to work as origiInally intended (and digging through the newsgroups will turn up several discussions on why, if you're interested). I don't bother with it anymore myself. DUB used to compile with it enabled by default, but no longer. I use it for intent. And I think it might affect overload sets? For example in my reflection library, I have a getValue function that returns metadata for a field or property, while getMethod would return it for just any old method.
Re: Getters/setters generator
On Sunday, 11 December 2016 at 03:15:55 UTC, Mike Bierlee wrote: On Sunday, 11 December 2016 at 02:17:18 UTC, Mike Parker wrote: On Saturday, 10 December 2016 at 20:25:05 UTC, Mike Bierlee wrote: On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote: It would generate 2 methods "num": one to set num_ and one to get its value. It would be great if you could generate @properties instead. I like the more natural way of accessing those instead of getters/setters. What are properties if not "getters" and "setters"? From the original post: "It would generate 2 methods "num": one to set num_ and one to get its value." Two methods named "num". No "get" or "set" in sight. I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters. Yeah, I see, @property seems to bring some additional features. Will think about it. Thanks.
Re: Getters/setters generator
On Saturday, 10 December 2016 at 16:37:53 UTC, Iakh wrote: On Friday, 9 December 2016 at 16:30:55 UTC, Eugene Wissner wrote: On Friday, 9 December 2016 at 12:37:58 UTC, Iakh wrote: Is there possibility to remove affixes in generated accessor names? No, there is no way to manipulate the accessor names. What affixes do you mean? You can remove suffix "_" so "name_" becomes "name". But I like to see genarated accessors "name" for field "m_name" no, it isn't possible. we just hard coded the most simple and the most "d-style" convention.
Re: Getters/setters generator
On Sunday, 11 December 2016 at 03:15:55 UTC, Mike Bierlee wrote: I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters. Right, any no-arg function can be called without parentheses, and single-arg functions can be called as 'func = foo'. At this point, I don't think think @property is ever going to be fixed to work as originally intended (and digging through the newsgroups will turn up several discussions on why, if you're interested). I don't bother with it anymore myself. DUB used to compile with it enabled by default, but no longer.
Re: Getters/setters generator
On Sunday, 11 December 2016 at 02:17:18 UTC, Mike Parker wrote: On Saturday, 10 December 2016 at 20:25:05 UTC, Mike Bierlee wrote: On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote: It would generate 2 methods "num": one to set num_ and one to get its value. It would be great if you could generate @properties instead. I like the more natural way of accessing those instead of getters/setters. What are properties if not "getters" and "setters"? From the original post: "It would generate 2 methods "num": one to set num_ and one to get its value." Two methods named "num". No "get" or "set" in sight. I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters.
Re: Getters/setters generator
On Saturday, 10 December 2016 at 20:25:05 UTC, Mike Bierlee wrote: On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote: It would generate 2 methods "num": one to set num_ and one to get its value. It would be great if you could generate @properties instead. I like the more natural way of accessing those instead of getters/setters. What are properties if not "getters" and "setters"? From the original post: "It would generate 2 methods "num": one to set num_ and one to get its value." Two methods named "num". No "get" or "set" in sight.
Re: Getters/setters generator
On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote: It would generate 2 methods "num": one to set num_ and one to get its value. It would be great if you could generate @properties instead. I like the more natural way of accessing those instead of getters/setters.
Re: Getters/setters generator
On Friday, 9 December 2016 at 16:30:55 UTC, Eugene Wissner wrote: On Friday, 9 December 2016 at 12:37:58 UTC, Iakh wrote: Is there possibility to remove affixes in generated accessor names? No, there is no way to manipulate the accessor names. What affixes do you mean? You can remove suffix "_" so "name_" becomes "name". But I like to see genarated accessors "name" for field "m_name"
Re: Getters/setters generator
On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote:
Hello,
we've just open sourced a small module ("accessors") that helps
to generate getters and setters automatically:
https://github.com/funkwerk/accessors
http://code.dlang.org/packages/accessors
It takes advantage of the UDAs and mixins. A simple example
would be:
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
mixin(GenerateFieldAccessors);
}
It would generate 2 methods "num": one to set num_ and one to
get its value. Of cause you can generate only @Read without
@Write and vice versa. There are some more features, you can
find the full documentation in the README.
"GenerateFieldAccessors" mixin should be added into each
class/struct that wants to use auto generated accessors.
Oh my this is going to be a compiletime hog if used excessively.
Due the use of fqn.
Re: Getters/setters generator
On 12/9/16 5:27 AM, Eugene Wissner wrote:
Hello,
we've just open sourced a small module ("accessors") that helps to
generate getters and setters automatically:
https://github.com/funkwerk/accessors
http://code.dlang.org/packages/accessors
It takes advantage of the UDAs and mixins. A simple example would be:
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
mixin(GenerateFieldAccessors);
}
It would generate 2 methods "num": one to set num_ and one to get its
value. Of cause you can generate only @Read without @Write and vice
versa. There are some more features, you can find the full documentation
in the README.
"GenerateFieldAccessors" mixin should be added into each class/struct
that wants to use auto generated accessors.
Love it, and was toying with similar ideas too. One good extension is to
add a predicate to the setter, which guards the assignment. -- Andrei
Re: Getters/setters generator
On Friday, 9 December 2016 at 12:37:58 UTC, Iakh wrote: Is there possibility to remove affixes in generated accessor names? No, there is no way to manipulate the accessor names. What affixes do you mean?
Re: Getters/setters generator
mixin template GenerateFieldAccessorMethods()
{
static enum GenerateFieldAccessorMethods()
{
string result = "";
return result;
}
}
Strange syntax
Re: Getters/setters generator
On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote:
Hello,
we've just open sourced a small module ("accessors") that helps
to generate getters and setters automatically:
https://github.com/funkwerk/accessors
http://code.dlang.org/packages/accessors
It takes advantage of the UDAs and mixins. A simple example
would be:
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
mixin(GenerateFieldAccessors);
}
It would generate 2 methods "num": one to set num_ and one to
get its value. Of cause you can generate only @Read without
@Write and vice versa. There are some more features, you can
find the full documentation in the README.
"GenerateFieldAccessors" mixin should be added into each
class/struct that wants to use auto generated accessors.
Is there possibility to remove affixes in generated accessor
names?
