Thread overview
Food for thought
Feb 12, 2007
Robby
Re: Food for thought [generalizing array methods]
Feb 12, 2007
Mike Capp
Feb 13, 2007
Johan Granberg
Feb 13, 2007
Don Clugston
Feb 13, 2007
Dave
Feb 14, 2007
Don Clugston
Feb 14, 2007
Dave
Feb 14, 2007
Lutger
Feb 15, 2007
Bruno Medeiros
February 12, 2007
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 representation to C#'s basic types as struct idiom.

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?
February 12, 2007
> 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.
February 13, 2007
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 representation to C#'s basic types as struct idiom.
> 
> 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.
February 13, 2007
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.
February 13, 2007
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.
February 14, 2007
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.
February 14, 2007
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.
February 14, 2007
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...
February 15, 2007
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