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