digitalmars.D.learn - Adding properties/members to base types?
- Steven Schveighoffer (14/14) Sep 05 2007 I must be going crazy, but I thought this behavior was implemented in D.
- Kirk McDonald (8/29) Sep 05 2007 This currently works only for the array types. It was proposed to
- Steven Schveighoffer (8/10) Sep 05 2007 Kirk,
- Bill Baxter (12/23) Sep 05 2007 That makes me nervous too. It's hard enough having to search up the
- Christopher Wright (8/10) Sep 05 2007 With good IDEs. (If they solve it at all, that is.)
- Kirk McDonald (9/41) Sep 05 2007 This is why I am a big, big fan of selective imports (and to a lesser
- Robert Fraser (2/18) Sep 05 2007 Use a semantic-aware IDE.
- Daniel Keep (7/20) Sep 05 2007 Heaven knows we don't have the exact same problem with free functions,
- Bill Baxter (6/30) Sep 05 2007 Point taken. If you're sloppy about namespaces to begin with this will
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
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. -SteveThis 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
"Kirk McDonald" wroteThis 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
Steven Schveighoffer wrote:"Kirk McDonald" wroteThat 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. --bbThis 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.
Sep 05 2007
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
Bill Baxter wrote:Steven Schveighoffer wrote: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"Kirk McDonald" wroteThat 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. --bbThis 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.
Sep 05 2007
Steven Schveighoffer Wrote:"Kirk McDonald" wroteUse a semantic-aware IDE.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
Steven Schveighoffer wrote:"Kirk McDonald" wroteHeaven 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: :PThis 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
Daniel Keep wrote:Steven Schveighoffer wrote: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"Kirk McDonald" wroteHeaven 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: :PThis 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