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

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.  ;)

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. :-)

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