www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Adding properties/members to base types?

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
I must be going crazy, but I thought this behavior was implemented in D.

Is this just something someone proposed as an enhancement or is it real?

int myfunc(int x)
{
   return x + 5;
}

int test()
{
  int m = 10;
  return m.myfunc;  // implicitly knows that it should call myfunc(m)
}

I can't find anywhere that this is mentioned, but I swear I read it 
somewhere, either in a newsgroup post or the D specs.

-Steve 
Sep 05 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Steven Schveighoffer wrote:
 I must be going crazy, but I thought this behavior was implemented in D.
 
 Is this just something someone proposed as an enhancement or is it real?
 
 int myfunc(int x)
 {
    return x + 5;
 }
 
 int test()
 {
   int m = 10;
   return m.myfunc;  // implicitly knows that it should call myfunc(m)
 }
 
 I can't find anywhere that this is mentioned, but I swear I read it 
 somewhere, either in a newsgroup post or the D specs.
 
 -Steve 
 
 
This currently works only for the array types. It was proposed to generalize it for all types. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Sep 05 2007
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Kirk McDonald" wrote
 This currently works only for the array types. It was proposed to 
 generalize it for all types.
Kirk, Thanks, that is where I read it. For some reason I couldn't find it. I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :) Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is. -Steve
Sep 05 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Steven Schveighoffer wrote:
 "Kirk McDonald" wrote
 This currently works only for the array types. It was proposed to 
 generalize it for all types.
Kirk, Thanks, that is where I read it. For some reason I couldn't find it. I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :) Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is.
That makes me nervous too. It's hard enough having to search up the inheritance hierarchy to find out where 'bar' is implemented when you run across "foo.bar()". But if you also have to potentially examine *every* import as well... oh boy. Another option would be to make them non-importable. So then you know it's either defined somewhere in the inheritance chain or in the local file. But that would probably just lead to people working around it using mixin(import(...)). Apparently other languages have this feature though. I'm curious how they avoid the maintenance nightmare. --bb
Sep 05 2007
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Bill Baxter wrote:
 Apparently other languages have this feature though.  I'm curious how 
 they avoid the maintenance nightmare.
With good IDEs. (If they solve it at all, that is.) I would like to see it work with static imports, though: static import foo; int i; int j = i.foo.frob; You're far less likely to confuse that than if you had to dynamically (?) import frob to use the member syntax.
Sep 05 2007
prev sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:
 Steven Schveighoffer wrote:
 
 "Kirk McDonald" wrote

 This currently works only for the array types. It was proposed to 
 generalize it for all types.
Kirk, Thanks, that is where I read it. For some reason I couldn't find it. I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :) Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is.
That makes me nervous too. It's hard enough having to search up the inheritance hierarchy to find out where 'bar' is implemented when you run across "foo.bar()". But if you also have to potentially examine *every* import as well... oh boy. Another option would be to make them non-importable. So then you know it's either defined somewhere in the inheritance chain or in the local file. But that would probably just lead to people working around it using mixin(import(...)). Apparently other languages have this feature though. I'm curious how they avoid the maintenance nightmare. --bb
This is why I am a big, big fan of selective imports (and to a lesser extent static imports): You always know exactly what you are importing and from where. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Sep 05 2007
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Steven Schveighoffer Wrote:

 
 "Kirk McDonald" wrote
 This currently works only for the array types. It was proposed to 
 generalize it for all types.
Kirk, Thanks, that is where I read it. For some reason I couldn't find it. I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :) Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is. -Steve
Use a semantic-aware IDE.
Sep 05 2007
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Steven Schveighoffer wrote:
 "Kirk McDonald" wrote
 This currently works only for the array types. It was proposed to 
 generalize it for all types.
Kirk, Thanks, that is where I read it. For some reason I couldn't find it. I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :) Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is. -Steve
Heaven knows we don't have the exact same problem with free functions, since you can always tell where they're coming from. And hell, you *always* have the ability to modify a class or struct's definition, so there's no reason to ever create a free function! -- Daniel P.S. For those that don't know me very well: :P
Sep 05 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Daniel Keep wrote:
 
 Steven Schveighoffer wrote:
 "Kirk McDonald" wrote
 This currently works only for the array types. It was proposed to 
 generalize it for all types.
Kirk, Thanks, that is where I read it. For some reason I couldn't find it. I hope it does get added, but only for basic types/enums, because allowing it for classes/structs would confuse the hell out of me :) Not only would you have to look through class definitions/base classes, but also randomly placed functions to find out what the definition of some class property is. -Steve
Heaven knows we don't have the exact same problem with free functions, since you can always tell where they're coming from. And hell, you *always* have the ability to modify a class or struct's definition, so there's no reason to ever create a free function! -- Daniel P.S. For those that don't know me very well: :P
Point taken. If you're sloppy about namespaces to begin with this will just make it worse. If you're tidy, it'll be no problem because every such function you're using will have to be explicitly imported into the namespace. Yet another reason static import should be the default. --bb
Sep 05 2007