www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Property and method groups

reply Sjoerd van Leent <svanleent gmail.com> writes:
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
Jul 31 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Jul 31, 2009 at 5:37 AM, Sjoerd van Leent<svanleent gmail.com> wrot=
e:

 It appears that there are really different discussions about properties. =


There is a discussion about letting properties look and act as much as fiel=
ds, and there is a discussion about calling member methods on returning str=
ucts.

 I'd like to seperate these discussions. First, I don't think it is wise t=


o 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 dif=
ferent 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
 {
 =A0 group bar
 =A0 {
 =A0 =A0 =A0int foo()
 =A0 =A0 =A0{
 =A0 =A0 =A0 =A0 return 123;
 =A0 =A0 =A0}
 =A0 =A0 =A0void foo(int i)
 =A0 =A0 =A0{
 =A0 =A0 =A0 =A0 // do something spectacular
 =A0 =A0 =A0}
 =A0 }
 }

 This could be called as:

 auto o =3D new A();
 auto i =3D o.bar.foo;
 o.bar.foo =3D 123;

 Fun thing about groups is that it is much more flexible. For example, bas=


ic 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.  ;)
Jul 31 2009
parent Sjoerd van Leent <svanleent gmail.com> writes:
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. :-)
Jul 31 2009
prev sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
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
Jul 31 2009