Keyword for direct access of the outer from the inner of nested classes, the "context pointer".

"
Non-static nested classes work by containing an extra hidden member (called
the context pointer) that

is the frame pointer of the enclosing function if it is nested inside a function, or the this of the enclosing

class's instance if it is nested inside a class.
When a non-static nested class is instantiated, the context pointer is
assigned before the class's

constructor is called, therefore the constructor has full access to the
enclosing variables.
"
these words are from the document of D Programming Language.

I know this topic has been discussed some times, but i strongly like feature
to be added in the future.
I thought it is not reasonable if you can access all members of the outer
class but not itself from within

the inner class.
Some one suggest the solution of creating a field and assigning this to it
in the outer ctor:
class Outer {
 Outer ctx;
 class Inner {
  void foo() {
   bar(ctx);
  }
 }
 this() {
  ctx=this;
 }
}
but it's not much convenient.

Since the "non-static nested classes work by containing an extra hidden member (called the context

pointer)", why not just expose it to us?

""" if we have such a keyword: context / ctx / enclosure / outer or somewhat?

here a real example, from my DWT app codes, (that's why i want this?)

class QKDataTab : CTabFolder {

 class ScriptTabItem : CTabItem {
  Text script;
  this(QKDataTab parent) {
   super(parent, DWT.CLOSE);
   setImage(_app.getIcon("demo"));
   setControl(script=new Text(parent,

DWT.MULTI|DWT.V_SCROLL|DWT.BORDER));
  }
  ...
 }
 /// if we have "enclosure" here, we can rewrite the above as:
 ///class ScriptTabItem : CTabItem {
 /// Text script;
 /// this() {
 ///  super(enclosure, DWT.CLOSE);
 ///  setImage(_app.getIcon("demo"));
 ///  setControl(script=new Text(enclosure,

DWT.MULTI|DWT.V_SCROLL|DWT.BORDER));
 /// }
  ...
 ///}
 ///that's much reasonable.

 QKApp _app;

 this(Composite parent, QKApp app) {
  _app = app;
  super(parent, DWT.TOP|DWT.BORDER);
  setSimple(true);
  initComponents();
 }
 void initComponents() {
  ...
 }

 ScriptTabItem addScriptTabItem(char[] title) {
  ScriptTabItem sti = new ScriptTabItem(this);
  sti.setText(title);
  setSelection(sti);
  _app.mainToolBar.enableItemExecute();
  return sti;
 }
 ScriptTabItem getSelectionScript() {
  return cast(ScriptTabItem)getSelection();
 }
 ...

}

some thought?

icee wrote:
> Keyword for direct access of the outer from the inner of nested classes, the "context pointer".

I agree 100% on this. This is really missing. There is a workaround but it is IMO stupid to have to add a member to outer class that a inner class can access something it already contains (hidden).

Ivan Senji wrote:
> icee wrote:
>> Keyword for direct access of the outer from the inner of nested classes, the "context pointer".
> 
> I agree 100% on this. This is really missing. There is a workaround but it is IMO stupid to have to add a member to outer class that a inner class can access something it already contains (hidden).

I second that. Frank Benoit has proposed the keyword 'outer' before and I'm surprised the idea hasn't been adapted yet.

Tom S wrote:
> Ivan Senji wrote:
>> icee wrote:
>>> Keyword for direct access of the outer from the inner of nested classes, the "context pointer".
>>
>> I agree 100% on this. This is really missing. There is a workaround but it is IMO stupid to have to add a member to outer class that a inner class can access something it already contains (hidden).
> 
> I second that. Frank Benoit has proposed the keyword 'outer' before and I'm surprised the idea hasn't been adapted yet.

Heh. Proves what /I/ know.  I thought we *already* had it (I must be thinking in Java).

It really should be in the language.

-- 
- EricAnderton at yahoo

"Pragma" <ericanderton@yahoo.removeme.com> wrote in message news:efjrcf$ihv$1@digitaldaemon.com...
> Tom S wrote:
>> Ivan Senji wrote:
>>> icee wrote:
>>>> Keyword for direct access of the outer from the inner of nested classes, the "context pointer".
>>>
>>> I agree 100% on this. This is really missing. There is a workaround but it is IMO stupid to have to add a member to outer class that a inner class can access something it already contains (hidden).
>>
>> I second that. Frank Benoit has proposed the keyword 'outer' before and I'm surprised the idea hasn't been adapted yet.
>
> Heh. Proves what /I/ know.  I thought we *already* had it (I must be thinking in Java).
>
> It really should be in the language.

I fourth it.

Java use explicit class name to access outer this, like "Outer.this", but I
think D can go beyond this by using a keyword.
the Only problem may be to find a keyword which we both agree on and is not
likely to mess the existing codes.
I prefer "ctx_this" which is rarely used, i think.
thix??

icee wrote:
> Java use explicit class name to access outer this, like "Outer.this", but I think D can go beyond this by using a keyword.
> the Only problem may be to find a keyword which we both agree on and is not likely to mess the existing codes.
> I prefer "ctx_this" which is rarely used, i think.

Uh, "ctx_this" is ugly, what is wrong with just "outer"?

> thix??

Hmm.

>
> Uh, "ctx_this" is ugly, what is wrong with just "outer"?
>
sometime, i just like some ugly or strange things.
joke.

DMD .168 adds the .outer property, so it's resolved, thanks.