digitalmars.D.learn - Pseudo member functions
- Derek Parnell (22/22) May 11 2005 As you all know, functions of the form ...
- Derek Parnell (7/10) May 11 2005 I have found one form that works!
- John Reimer (36/67) May 11 2005 Good question. I don't know if there are any slick solutions. I could
- John Reimer (1/6) May 11 2005 Oops! "import importable;" is supposed to be "import other;"
- Ben Hinkle (5/12) May 12 2005 public service announcement for new readers: I vaguely recall from Walte...
- B.G. (9/29) May 13 2005 Oh, always wanted to ask about this.
- David L. Davis (11/40) May 13 2005 Walter answered pretty positive about leaving this trick be, in his repl...
- Ben Hinkle (4/12) May 13 2005 Well I'll be darned - it looks like he does say he'll document it. I tho...
- B.G. (19/68) May 13 2005 I love everything looking nice and being efficient.
- pragma (22/37) May 13 2005 I'm glad you asked this, because I was curious myself. As it turns out,...
- Andrew Fedoniouk (28/28) May 13 2005 Initially I was using this approach
As you all know, functions of the form ... func( char[] s, int i) can be used in you code as ... char[] x; x.func(a); I'm calling this usage a "pseudo-member function" for want of a better term. But if the function is defined in a different module, and one needs to disambiguate the function reference, what is the correct syntax for using the function as a pseudo-member function? I know how to call it using traditional syntax ... othermod.func(x,a); but I'm not sure of the other format. It is not x.othermod.func(a); nor x.(othermod.func)(a); Any ideas anyone? -- Derek Melbourne, Australia 12/05/2005 12:58:16 PM
May 11 2005
On Thu, 12 May 2005 13:05:41 +1000, Derek Parnell wrote:... if the function is defined in a different module, and one needs to disambiguate the function reference, what is the correct syntax for using the function as a pseudo-member function?I have found one form that works! with (othermod) x.func(a); -- Derek Parnell Melbourne, Australia 12/05/2005 2:15:39 PM
May 11 2005
Derek Parnell wrote:As you all know, functions of the form ... func( char[] s, int i) can be used in you code as ... char[] x; x.func(a); I'm calling this usage a "pseudo-member function" for want of a better term. But if the function is defined in a different module, and one needs to disambiguate the function reference, what is the correct syntax for using the function as a pseudo-member function? I know how to call it using traditional syntax ... othermod.func(x,a); but I'm not sure of the other format. It is not x.othermod.func(a); nor x.(othermod.func)(a); Any ideas anyone?Good question. I don't know if there are any slick solutions. I could only think up these possibilities: In short, there doesn't seem to be a way using the fully qualified name alone. -JJR
May 11 2005
Oops! "import importable;" is supposed to be "import other;"
May 11 2005
"Derek Parnell" <derek psych.ward> wrote in message news:1hxdwuep1skbe.11d735ffbmq1g.dlg 40tude.net...As you all know, functions of the form ... func( char[] s, int i) can be used in you code as ... char[] x; x.func(a); I'm calling this usage a "pseudo-member function" for want of a better term.public service announcement for new readers: I vaguely recall from Walter that it was an implementation atrifact and isn't part of the language spec - hence unsupported.
May 12 2005
Ben Hinkle wrote:"Derek Parnell" <derek psych.ward> wrote in message news:1hxdwuep1skbe.11d735ffbmq1g.dlg 40tude.net...Oh, always wanted to ask about this. So this 'feature' is considered to be a bug and a bad thing, right? I haven't written a lot of D programs, but this is a cool feature to write nice code (and to not using classes for strings :-) This would hurt me if this feature would be dropped. As I've lurked in some forums, this feature is being appreciated by many, so if there's a serious reason to forbid this feature, I'd really want to know why. Regards!As you all know, functions of the form ... func( char[] s, int i) can be used in you code as ... char[] x; x.func(a); I'm calling this usage a "pseudo-member function" for want of a better term.public service announcement for new readers: I vaguely recall from Walter that it was an implementation atrifact and isn't part of the language spec - hence unsupported.
May 13 2005
In article <d62jqm$2fd7$1 digitaldaemon.com>, B.G. says...Ben Hinkle wrote:Walter answered pretty positive about leaving this trick be, in his reply on the 3th of March 2005 found below: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18038 David L. P.S. I've started using this trick in my code just recently myself...I really like it a lot!! :) ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!" ------------------------------------------------------------------- MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html"Derek Parnell" <derek psych.ward> wrote in message news:1hxdwuep1skbe.11d735ffbmq1g.dlg 40tude.net...Oh, always wanted to ask about this. So this 'feature' is considered to be a bug and a bad thing, right? I haven't written a lot of D programs, but this is a cool feature to write nice code (and to not using classes for strings :-) This would hurt me if this feature would be dropped. As I've lurked in some forums, this feature is being appreciated by many, so if there's a serious reason to forbid this feature, I'd really want to know why. Regards!As you all know, functions of the form ... func( char[] s, int i) can be used in you code as ... char[] x; x.func(a); I'm calling this usage a "pseudo-member function" for want of a better term.public service announcement for new readers: I vaguely recall from Walter that it was an implementation atrifact and isn't part of the language spec - hence unsupported.
May 13 2005
Walter answered pretty positive about leaving this trick be, in his reply on the 3th of March 2005 found below: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18038 David L. P.S. I've started using this trick in my code just recently myself...I really like it a lot!! :)Well I'll be darned - it looks like he does say he'll document it. I thought he stepped back from that statement later in the thread but I can't find any reply that says otherwise so it looks like I was mistaken. -Ben
May 13 2005
David L. Davis wrote:In article <d62jqm$2fd7$1 digitaldaemon.com>, B.G. says...I love everything looking nice and being efficient. It's extremely usefull with functions operating on char[]. Using this technique, they are applied like they were methods of some String class, but they're just syntactic sugar, and no string class wrappers are needed. That's is infinitely cool :) The only thing that itches, are templated functions and functions from another module referenced with the full qualified path. From earlier threads, for templated functions aliases need to be defined for the whole thing to work, which is IMHO not cool. I don't know if it's possible, but, if there is a templated function for which we might somehow know that it's template parameter is always supposed to be an _array_, compiler could theoretically be able to choose the 'right' templated function without a need to define an alias. ======== BTW. I've already heared about 5 different names everybody gives to this 'phenomenon'. Is there an official name for this? is this 'Pseudo member functions' or it's another subjective attempt to give it a name?Ben Hinkle wrote:Walter answered pretty positive about leaving this trick be, in his reply on the 3th of March 2005 found below: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18038 David L. P.S. I've started using this trick in my code just recently myself...I really like it a lot!! :)"Derek Parnell" <derek psych.ward> wrote in message news:1hxdwuep1skbe.11d735ffbmq1g.dlg 40tude.net...Oh, always wanted to ask about this. So this 'feature' is considered to be a bug and a bad thing, right? I haven't written a lot of D programs, but this is a cool feature to write nice code (and to not using classes for strings :-) This would hurt me if this feature would be dropped. As I've lurked in some forums, this feature is being appreciated by many, so if there's a serious reason to forbid this feature, I'd really want to know why. Regards!As you all know, functions of the form ... func( char[] s, int i) can be used in you code as ... char[] x; x.func(a); I'm calling this usage a "pseudo-member function" for want of a better term.public service announcement for new readers: I vaguely recall from Walter that it was an implementation atrifact and isn't part of the language spec - hence unsupported.
May 13 2005
In article <d62suf$2mrk$1 digitaldaemon.com>, B.G. says...I don't know if it's possible, but, if there is a templated function for which we might somehow know that it's template parameter is always supposed to be an _array_, compiler could theoretically be able to choose the 'right' templated function without a need to define an alias.I'm glad you asked this, because I was curious myself. As it turns out, D uses the rather unintuitive rule "T:T[]" to require an array template type.template x(T:T[]){ /* arrays only, T = aggregate type */ } template x(T){ /* everything else */ }Which makes some sense, given that if we want T to assume the actual type passed, we'd use "T[]" or just "T". Some other handy template rules is use are:template x(T:Object){ /* objects only */ } template x(T:T*){ /* pointers only, T = aggregate type */ }Structs are lumped in with scalar types (no common base class), so there's no equivalent for the 'Object' rule above. Likewise, delegates and functions have no such equivalent, as you need to specify the entire delegate/function type.template x(T:struct){ /* won't compile */ } template x(T:delegate){ /* won't compile */ } template x(T:void delegate()){ /* works (use aliases for cleaner code!) */ }Anoter tip: Sometimes, I like to declare template sets with rules for types I don't want the user to use under any circumstance. This goes especially if the template i've defined is too general, and might match types that wouldn't apply. Then I pack the template definition with a "pragma(msg)" along with a "static assert(false)" to warn the unwary developer. This way, compilation grinds to a halt and the developer is told why.BTW. I've already heared about 5 different names everybody gives to this 'phenomenon'. Is there an official name for this? is this 'Pseudo member functions' or it's another subjective attempt to give it a name?AFAIK, there is no 'official' name for this feature. The title 'pseudo member functions' is about as close as we get. It's definately better than what it really is: 'automatic member-like alias for array types' or an 'outer namespace declared associated member'. I'm sure the CS crowd out there could come up with a few other more offical-sounding names. - EricAnderton at yahoo
May 13 2005
Initially I was using this approach but stopped for many reasons. What could be done instead of "pseudo-member function" (I am calling them: "external methods") ? Let's say I would like to have "pseudo-member function" for wchar[] type bool wchar[].like(wchar[] pattern) { .... } in Harmonia I've created special wrapper struct string { wchar[] chars; static opCall(wchar[] s) { string s; s.chars = s; return s; } bool like(wchar[] pattern) { .... } } Having this I am doing following when I need 'like' ubyte[] loadFromUrl( wchar[] s ) { if( string(s).like("file://*") ) ..... } So I am not using 'string' as a type of variable but rather as a namespace designator. This shift of struct paradigm is a bit ugly (and probably less efficient a bit) but works. This does not prevent to use string as a type of variable though. But it does not allow you to have static variables of such strings.... (no ctors in structs!) I am using string as a typename in harmonia.ui.controls.behaviors.LineEditor as type of dynamic text buffer. Andrew.
May 13 2005