On Wednesday, 26 June 2013 at 07:35:08 UTC, Namespace wrote:
On Tuesday, 25 June 2013 at 23:39:45 UTC, Ali Çehreli wrote:
With apologies, I have unrelated comments to make.
On 06/25/2013 03:07 PM, Namespace wrote:
> this(T x, T y) {
> this.x = x;
> this.y = y;
>
> points ~= &this._point;
I have seen similar designs in the past where constructors had
side-effects such as registering the object in a global state.
(Exactly what the last line is doing above.)
It has almost always been cause of trouble. It is better to
register an object from the outside after constructing it.
Sometimes I had attempted to remove seemingly unused objects
only to be reminded by a comment that it should not be:
// Do not remove! Registers itself in the points array
auto p = Point();
> @property
> inout(Point)* ptr() inout {
> points[this.id].x = cast(int) this.x;
> points[this.id].y = cast(int) this.y;
That looks questionable as well: ptr() looks like an accessor
but it makes changes to a global state.
Ali
This is no real code. Just a test example to check. ;)
It seems safe, however, your example seems to show how to indeed
break the type system... without a cast (!):
@property
Point* ptr() inout {
points[this.id].x = cast(int) this.x;
points[this.id].y = cast(int) this.y;
return points[this.id];
}
void main() {
immutable TplPoint!float my = TplPoint!float(42, 23);
Point* p = my.ptr; //Oops! mutable point!
}
Disturbing...
this(T x, T y) {
this.x = x;
this.y = y;
points ~= &this._point;
I'd careful with this, you can easily end up with pointers to
destroyed temporaries...
