www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Food for thought

reply Robby <robby.lansaw gmail.com> writes:
The implementation of array methods to me is one of the sexiest, and yet 
quietest features of D. Probably do to the duh factor, but none the 
less. (any method that has an array as the first argument can use a 
shortened syntax)

how much machinery would it entail to make this avail to all basic types 
instead of just arrays? To me this would really allow me (and I'm 
assuming others) to improve readability of the code written, and while 
all basic types aren't object based, it allows us to treat them as 
objects in code. Or even treat them as if they were a struct (similar 


consider a character example
bool isLower(char c)
{
	if ('a' <= c && c <= 'z')
		return true;
	return false;
}	
While it's just as easy to have isLower('a') the readability comes in 
with 'a'.isLower()

And if the methods could be treated as properties we could have 
something similar to
5.sqr (though I'd be just as thrilled with 5.sqr())

So I'm asking, since there is base implementation for the machinery for 
arrays, how hard would it be to implement the machinery for all basic types?

Is there any side effects to this I'm not thinking of?

Would it be fair to consider that the compiler can optimize such cases?
Feb 12 2007
next sibling parent Mike Capp <mike.capp gmail.com> writes:
 how much machinery would it entail to make [array
 methods] available to all basic types instead of
 just arrays?
If you're going to support it for arrays and basic types, why not go the whole hog and support it for everything? This has a number of benefits: 1) Consistency, obviously. 2) Allows you to seamlessly extend a class (possibly one for which you don't have source) without hurting encapsulation; everything has to go through the "real" class interface, so all invariants should be covered by existing checks. Scott Meyers was talking about this "minimal interface" ideal ages ago. 3) Greater discoverability and convenience in IDEs etc. You can type "myFoo." and the tool can suggest "myFuncTakingFoo()". When the function comes first the tool is faced with a blank slate; there's nothing to hang suggestions off. Not sure what the costs would be, but I'd expect headaches with e.g. overload resolution. I vaguely recall that Francis Glassborow had a similar C++0x proposal a few years back and it didn't get much traction. I suppose there'd also be a worry that this would allow member-function syntax where it didn't make semantic sense. You wouldn't want to call write(bool flushBuffers, string text) as true.write("hello"); There's a similar concern already with class property syntax.
Feb 12 2007
prev sibling next sibling parent Johan Granberg <lijat.meREM OVE.gmail.com> writes:
Robby wrote:

 The implementation of array methods to me is one of the sexiest, and yet
 quietest features of D. Probably do to the duh factor, but none the
 less. (any method that has an array as the first argument can use a
 shortened syntax)
 
 how much machinery would it entail to make this avail to all basic types
 instead of just arrays? To me this would really allow me (and I'm
 assuming others) to improve readability of the code written, and while
 all basic types aren't object based, it allows us to treat them as
 objects in code. Or even treat them as if they were a struct (similar

 
 consider a character example
 bool isLower(char c)
 {
 if ('a' <= c && c <= 'z')
 return true;
 return false;
 }
 While it's just as easy to have isLower('a') the readability comes in
 with 'a'.isLower()
 
 And if the methods could be treated as properties we could have
 something similar to
 5.sqr (though I'd be just as thrilled with 5.sqr())
 
 So I'm asking, since there is base implementation for the machinery for
 arrays, how hard would it be to implement the machinery for all basic
 types?
 
 Is there any side effects to this I'm not thinking of?
 
 Would it be fair to consider that the compiler can optimize such cases?
Yes this is something I have wanted a long time. Pleas implement this Walter.
Feb 13 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Robby wrote:
 The implementation of array methods to me is one of the sexiest, and yet 
 quietest features of D. Probably do to the duh factor, but none the 
 less. (any method that has an array as the first argument can use a 
 shortened syntax)
IIRC, it's quiet because it was originally a bug. Albeit a very popular one. And that's why it only works in a peculiar subset of cases. Even for arrays, it doesn't work for operator overloading, unfortunately. I wonder if Walter's worked out why it works <g>. (Mind you, the list of Easter eggs that have appeared in D is getting pretty impressive -- maybe it's a half-implemented feature rather than a bug). It would indeed be fabulous if it worked all cases.
Feb 13 2007
parent reply Dave <Dave_member pathlink.com> writes:
Don Clugston wrote:
 Robby wrote:
 The implementation of array methods to me is one of the sexiest, and 
 yet quietest features of D. Probably do to the duh factor, but none 
 the less. (any method that has an array as the first argument can use 
 a shortened syntax)
IIRC, it's quiet because it was originally a bug. Albeit a very popular one. And that's why it only works in a peculiar subset of cases. Even for arrays, it doesn't work for operator overloading, unfortunately. I wonder if Walter's worked out why it works <g>. (Mind you, the list of
I don't think it was ever unintentional: expression.c, line 4895 (v1.005)
 Easter eggs that have appeared in D is getting pretty impressive -- 
 maybe it's a half-implemented feature rather than a bug).
 
 It would indeed be fabulous if it worked all cases.
Feb 13 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Dave wrote:
 Don Clugston wrote:
 Robby wrote:
 The implementation of array methods to me is one of the sexiest, and 
 yet quietest features of D. Probably do to the duh factor, but none 
 the less. (any method that has an array as the first argument can use 
 a shortened syntax)
IIRC, it's quiet because it was originally a bug. Albeit a very popular one. And that's why it only works in a peculiar subset of cases. Even for arrays, it doesn't work for operator overloading, unfortunately. I wonder if Walter's worked out why it works <g>. (Mind you, the list of
I don't think it was ever unintentional: expression.c, line 4895 (v1.005)
OK, I've finally begun an Easter egg list <g>. http://www.prowiki.org/wiki4d/wiki.cgi?EasterEggs
 
 Easter eggs that have appeared in D is getting pretty impressive -- 
 maybe it's a half-implemented feature rather than a bug).

 It would indeed be fabulous if it worked all cases.
Feb 14 2007
next sibling parent Dave <Dave_member pathlink.com> writes:
Don Clugston wrote:
 Dave wrote:
 Don Clugston wrote:
 Robby wrote:
 The implementation of array methods to me is one of the sexiest, and 
 yet quietest features of D. Probably do to the duh factor, but none 
 the less. (any method that has an array as the first argument can 
 use a shortened syntax)
IIRC, it's quiet because it was originally a bug. Albeit a very popular one. And that's why it only works in a peculiar subset of cases. Even for arrays, it doesn't work for operator overloading, unfortunately. I wonder if Walter's worked out why it works <g>. (Mind you, the list of
I don't think it was ever unintentional: expression.c, line 4895 (v1.005)
OK, I've finally begun an Easter egg list <g>. http://www.prowiki.org/wiki4d/wiki.cgi?EasterEggs
Cool <g> In the expression.c code above, there's mention that it should also work as something like: array.foo.bar.baz.func(arg2); // foo.bar.baz.func(array,arg2); I wonder if Walter's criteria for Easter Eggs is that they currently work, but there are some corner cases to solve yet?
 
 Easter eggs that have appeared in D is getting pretty impressive -- 
 maybe it's a half-implemented feature rather than a bug).

 It would indeed be fabulous if it worked all cases.
Feb 14 2007
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Don Clugston wrote:
 OK, I've finally begun an Easter egg list <g>.
 
 http://www.prowiki.org/wiki4d/wiki.cgi?EasterEggs
Wow nice, I hadn't noticed stringof. Sweet. Perhaps this can help to solve the problem with syntax highlighting in const string mixins: writefln( mixin( (2 + 3).stringof ) ); Talking about obfuscation...
Feb 14 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Don Clugston wrote:
 Dave wrote:
 Don Clugston wrote:
 Robby wrote:
 The implementation of array methods to me is one of the sexiest, and 
 yet quietest features of D. Probably do to the duh factor, but none 
 the less. (any method that has an array as the first argument can 
 use a shortened syntax)
IIRC, it's quiet because it was originally a bug. Albeit a very popular one. And that's why it only works in a peculiar subset of cases. Even for arrays, it doesn't work for operator overloading, unfortunately. I wonder if Walter's worked out why it works <g>. (Mind you, the list of
I don't think it was ever unintentional: expression.c, line 4895 (v1.005)
OK, I've finally begun an Easter egg list <g>. http://www.prowiki.org/wiki4d/wiki.cgi?EasterEggs
Hum... I don't think this counts as an easter egg, but I just recently found out that 'alias' are like textual macros, and do not actually bind to a target code entity. This mean you can alias an overload name, and use the overloads through the alias: -------------- import stdext.stdio; //import helpers; template Tpl(T : Object ) { const char[] msg = "Object"; } template Tpl(T : char ) { const char[] msg = "char"; } template Tpl() { const char[] msg = "()"; } void func(Object o) { writeln("func(Object)"); } void func(int a) { writeln("func(int)"); } void main(char[][] args) { alias Tpl Tpl2; pragma(msg, Tpl2!(char).msg); pragma(msg, Tpl2!(Object).msg); pragma(msg, Tpl2!().msg); alias func func2; func2(2); func2(new Object()); } -------------- Previously I thought alias declaration would bind to an actual target "definition unit". So, that explain why the stringof of an alias doesn't work correctly. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Feb 15 2007