Lack of `outer` keyword makes inner class dup implossible

S. user at pathlink.com
Sun Jul 16 01:01:51 PDT 2006


On 2006-07-15 02:10:17 -0700, "Derek Parnell" <derek at psych.ward> said:

> On Sat, 15 Jul 2006 17:50:11 +1000, S. <dnewsgr at mephit.kicks-ass.org>
> wrote:
> 
>> On 2006-07-14 21:10:41 -0700, "Derek Parnell" <derek at psych.ward> said:
> 
>> 
>>> Ok, assuming that 'nested' and 'inner' are synonymous in this
> 
>>> discussion,  it appears that their main purpose is to provide scope
> 
>>> limitation. That  is, the functionality provided by inner
> 
>>> classes/functions is restricted  to, and there by only relevant to, t
> he
>>> containing class/function.
>>>  I use inner functions this way because I can see their utility, but
> 
>>> can  someone supply a good inner class example? As far as I can see,
> 
>>> an  instance of an inner class only makes sense in the context of its
> 
>>> parent  class and is thus reliant on the 'outer' class for relevancy.
> 
>>> I'm having  trouble visualizing where this might be a Cool Thing(TM).
> 
>> 
>> I'm writing a Sudoku solver.  I have a Cell class, an individual cell
> is
>> only relevant in the context of the board.  It makes various things a
> 
>> Cell might want to do easier having access to information about the
> 
>> board it lives on.  I could pass it a board instance when I create it
> 
>> like I did originally, but I saw nested classes and thought it was a
> 
>> nifty feature.
> 
> So the main reason is so Cell objects can access the Board object's
> members.
> 
> This can also be done just by declaring the classes in the same module,
> and thus avoid the restrictions you are tripping up on.
> 
> ============= module board;
> 
> class Board
> {
>     private Cell[9][9] arena;
>     private int option_x;
>     private bool Solved()
>     {
>       . . .
>     }
>     . . .
> }
> 
> class Cell
> {
>     private Board owner;
> 
>     this(Board b)
>     {
>        if (b.option_x)
>        {
>          . . .
>        }
>        owner = b;
>     }
> 
>     this(Cell c)
>     {
>        owner = c.owner;
>     }
>     Cell dup()
>     {
>        return  new Cell(this);
>     }
> 
>     bool Set()
>     {
>       . . .
>       return owner.Solved();
>     }
> }
> 
> ===============
> Its just an alternative using current D syntax. No big deal ;-)
> 
> --
> Derek Parnell
> Melbourne, Australia

That's exactly what I said:

"I could pass it a board instance when I create it like I did 
originally, but I saw nested classes and thought it was a  nifty 
feature."

Inner classes obviate that.

-S.




More information about the Digitalmars-d mailing list