Thread overview | ||||||
---|---|---|---|---|---|---|
|
July 31, 2009 Property and method groups | ||||
---|---|---|---|---|
| ||||
It appears that there are really different discussions about properties. There is a discussion about letting properties look and act as much as fields, and there is a discussion about calling member methods on returning structs. I'd like to seperate these discussions. First, I don't think it is wise to call a member on a returning struct, because of the expectation that the underlying object knows about the change. Thus is not true for a struct. What I want to talk about is a completely different approach to the a.b.c problem, and with that I just make my own proposal, that is completely different from any other, which I call groups. Suppose we have a rather big class with many methods and properties, this could come in handy. My idea is to introduce groups, in some ways similar to the idea of namespaces. class A { group bar { int foo() { return 123; } void foo(int i) { // do something spectacular } } } This could be called as: auto o = new A(); auto i = o.bar.foo; o.bar.foo = 123; Fun thing about groups is that it is much more flexible. For example, basic and advanced methods can be separated, etc. Just my 2 cents |
July 31, 2009 Re: Property and method groups | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sjoerd van Leent | On Fri, Jul 31, 2009 at 5:37 AM, Sjoerd van Leent<svanleent@gmail.com> wrote: > It appears that there are really different discussions about properties. There is a discussion about letting properties look and act as much as fields, and there is a discussion about calling member methods on returning structs. > > I'd like to seperate these discussions. First, I don't think it is wise to call a member on a returning struct, because of the expectation that the underlying object knows about the change. Thus is not true for a struct. > > What I want to talk about is a completely different approach to the a.b.c problem, and with that I just make my own proposal, that is completely different from any other, which I call groups. > > Suppose we have a rather big class with many methods and properties, this could come in handy. My idea is to introduce groups, in some ways similar to the idea of namespaces. > > class A > { > group bar > { > int foo() > { > return 123; > } > void foo(int i) > { > // do something spectacular > } > } > } > > This could be called as: > > auto o = new A(); > auto i = o.bar.foo; > o.bar.foo = 123; > > Fun thing about groups is that it is much more flexible. For example, basic and advanced methods can be separated, etc. Man, it's 2006 all over again! http://www.digitalmars.com/d/archives/digitalmars/D/41903.html#N41905 And that thread was about - oh boy - properties. ;) |
July 31, 2009 Re: Property and method groups | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | Jarrett Billingsley Wrote:
> On Fri, Jul 31, 2009 at 5:37 AM, Sjoerd van Leent<svanleent@gmail.com> wrote:
> > It appears that there are really different discussions about properties. There is a discussion about letting properties look and act as much as fields, and there is a discussion about calling member methods on returning structs.
> >
> > I'd like to seperate these discussions. First, I don't think it is wise to call a member on a returning struct, because of the expectation that the underlying object knows about the change. Thus is not true for a struct.
> >
> > What I want to talk about is a completely different approach to the a.b.c problem, and with that I just make my own proposal, that is completely different from any other, which I call groups.
> >
> > Suppose we have a rather big class with many methods and properties, this could come in handy. My idea is to introduce groups, in some ways similar to the idea of namespaces.
> >
> > class A
> > {
> > group bar
> > {
> > int foo()
> > {
> > return 123;
> > }
> > void foo(int i)
> > {
> > // do something spectacular
> > }
> > }
> > }
> >
> > This could be called as:
> >
> > auto o = new A();
> > auto i = o.bar.foo;
> > o.bar.foo = 123;
> >
> > Fun thing about groups is that it is much more flexible. For example, basic and advanced methods can be separated, etc.
>
> Man, it's 2006 all over again!
>
> http://www.digitalmars.com/d/archives/digitalmars/D/41903.html#N41905
>
> And that thread was about - oh boy - properties. ;)
It's nice to be repetitive and say the same things that should've been implemented in D1 already. :-)
|
July 31, 2009 Re: Property and method groups | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sjoerd van Leent | On Fri, 31 Jul 2009 05:37:50 -0400, Sjoerd van Leent wrote: > It appears that there are really different discussions about properties. There is a discussion about letting properties look and act as much as fields, and there is a discussion about calling member methods on returning structs. > > I'd like to seperate these discussions. First, I don't think it is wise to call a member on a returning struct, because of the expectation that the underlying object knows about the change. Thus is not true for a struct. Sounds to me like you missed the beginning of the discussion: http://www.digitalmars.com/webnews/newsgroups.php? art_group=digitalmars.D&article_id=94225 |
Copyright © 1999-2021 by the D Language Foundation