Consider the following code.




#include "Engine/Canvas.ang"

/*
Class: Widget

This is the base class for all visible and interactive objects in IrreGUI.
*/
// IObject is a base class interface that I can easily store in C++ containers. *hinthinthinthinthinthinthinthinthinthinthinthint*
class Widget : IObject
{

Widget(Widget@ parent)
{
@m_Parent = @parent;
m_Pos.X = m_Pos.Y = m_Pos.Z = 0.f;
}

void set_Pos(Vector p)
{
m_Pos = p;
m_Geometry.SetPos(m_Pos);
for(uint i=0;i<m_Children.size;i++)
{
Widget@ w = @m_Children;
// I am unable to call w.Pos = w.Pos + p; within set_Pos.
SetPosWorkaround(w,p);
}
}

private void SetPosWorkaround(Widget@ w,Vector p) { w.Pos = w.Pos + p; }

const Vector get_Pos() { return m_Pos; }

private Rect m_Geometry;
private Vector m_Pos;
private Widget@ m_Parent;
private Widget@[] m_Children;

private bool m_IsFocused;
};
// vim: syntax=cpp


The compiler complains that Pos is not a member of Widget.

Is this a bug or a feature?

Try making the getter const.

i.e.

const Vector get_Pos() const { return m_Pos; }


It's not supposed to be possible to call set_Pos on the this object, but in your case you're not doing that, so this would be a bug. I'll look into it.

The opposite is pretty much true. I have had a few instances in my code where I can call a set_ funtion on this.

Let me rephrase: It is possible to use property accessors on 'this', but from within a property accessor the compiler will not call the same property accessor. Otherwise you'll end up with an endless loop.

Example:


class T
{
int a;
void set_a(int val) {a = val;}
}


The above code is allowed, but only because the access to a within the set_a() property accessors accesses the actual member, rather than calling set_a() again.



Anyway, the problem you found has now been fixed in revision 902.

Thanks,
Andreas