More D newb questions.

Me Here p9e883002 at sneakemail.com
Tue May 6 13:16:44 PDT 2008


Janice Caron wrote:

> But.... Suppose I replace the built in array type with my own custom
> container, Array. Then I can override opCat and opCat_r to give me
> 
>     MyArray ~ MyArray = MyArray
>     MyArray ~ char = MyArray
>     char ~ array = MyArray
> 
> However, there is no way I can persuade my custom container to give me
> the effect:
> 
>     char ~ char = MyArray
> 
> because the bottom line is, a container needs to know about its
> elements, but elements do not need to know about their container.

It doesn't need to. Think about how this would come about:

	char a = 'a';
	char b = 'b';
	MyArray ma = a ~ b;

The concatenation happens on the right hand side and forms an intermediate
result. If the built-in base types knew how to do that, then so long as you've
implemented opAssign taking a char[], then it doesn't need to /do/ anything. It
would just work.

> Allowing ~ to create arrays from primitive types would give built-in
> arrays an unfair advantage over custom arrays, and that alone should
> be enough reason to disallow it.

The 'problem' of "unfairness" doesn't arise--as a result of this anyway.
Though, the benefits of built-in types having an advantage is (or was), part
ofD's mission statement:

	C++ implements things like resizable arrays and string concatenation 
	as part of the standard library, not as part of the core language. 
	Not being part of the core language has several suboptimal consequences.

For my part, I said back there somewhere that my immediate problem is solved.
Discussioin beyond that point is about the (perceived) fallacies being offered
by way of explanation for the behaviour.

[ 'a', 'b', 'c', 'd' ] is neater and more elegant than 'a' ~ 'b' ~ 'c' ~ 'd';
so I'm happy with that.

The clumsyness and cost of having to do:

        s[ i .. i+10 ] = "" ~ toupper( s[ i .. i+10 ] );

is more of a problem.

Cheers, b.
-- 




More information about the Digitalmars-d mailing list