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.




 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