July 13, 2012
On 7/13/12 2:30 PM, Gor Gyolchanyan wrote:
> The whole point is to have it not static. I need it to be properly
> nested with the this.outer.

What would be the type of this.outer?

Andrei

July 13, 2012
On Fri, Jul 13, 2012 at 11:03 PM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 7/13/12 2:30 PM, Gor Gyolchanyan wrote:
>
>> The whole point is to have it not static. I need it to be properly nested with the this.outer.
>>
>
> What would be the type of this.outer?
>
> Andrei
>
>
For Fruit.Seed it's Fruit, for AppleSeed it's Apple. This makes sense because the Apple, which AppleSeed sees is the same object, which Fruit.Seed sees as it's base type Fruit.

-- 
Bye,
Gor Gyolchanyan.


July 13, 2012
On Fri, Jul 13, 2012 at 11:02 PM, Era Scarecrow <rtcvb32@yahoo.com> wrote:

> On Friday, 13 July 2012 at 18:55:28 UTC, travert@phare.normalesup.org(Christophe Travert) wrote:
>
>> "Era Scarecrow" , dans le message (digitalmars.D:172272), a écrit :
>>
>>>   Then perhaps have the inherited class within fruit?
>>>
>>> class Fruit {
>>>    class Seed {}
>>>    class Appleseed : Seed {}
>>> }
>>>
>>
>> But then AppleSeed doesn't know about Apple....
>>
>
> So I forgot the apple :P But then inner inheritance won't work.
>
>  class Fruit {
>   class Seed {}
>   class Apple {
>    class Appleseed : Seed {} //same error as before
>   }
>  }
>
>  If you make seed static, then Appleseed & apple will have access to Fruit
> but seed (by itself) won't. Other combinations faile as far as I can tell.
> How far you can take inner class inheritance I don't know, but it seems not
> that many levels.
>

This all won't work, because having Fruit know about Apple defeats the whole purpose.

-- 
Bye,
Gor Gyolchanyan.


July 13, 2012
On 7/13/12 3:07 PM, Gor Gyolchanyan wrote:
> On Fri, Jul 13, 2012 at 11:03 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>
>     On 7/13/12 2:30 PM, Gor Gyolchanyan wrote:
>
>         The whole point is to have it not static. I need it to be properly
>         nested with the this.outer.
>
>
>     What would be the type of this.outer?
>
>     Andrei
>
>
> For Fruit.Seed it's Fruit, for AppleSeed it's Apple. This makes sense
> because the Apple, which AppleSeed sees is the same object, which
> Fruit.Seed sees as it's base type Fruit.

That would mean AppleSeed has two outer fields: a Fruit and an Apple.

Andrei

July 13, 2012
Andrei Alexandrescu , dans le message (digitalmars.D:172280), a écrit :
>> For Fruit.Seed it's Fruit, for AppleSeed it's Apple. This makes sense because the Apple, which AppleSeed sees is the same object, which Fruit.Seed sees as it's base type Fruit.
> 
> That would mean AppleSeed has two outer fields: a Fruit and an Apple.

Only one. Apple. And when AppleSeed.super seed this Apple, it sees a fruit.

AppleSeed a;
assert(is(typeof(a.outer) == Apple));
assert(is(typeof(a.super) == Seed));
assert(is(typeof(a.super.outer) == Fruit));
//but:
assert(a.outer is a.super.outer);

If you can't figure out how can a.outer and a.super.outer have two different types, but be the same, think about covariant return.


July 13, 2012
On Fri, Jul 13, 2012 at 11:10 PM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 7/13/12 3:07 PM, Gor Gyolchanyan wrote:
>
>> On Fri, Jul 13, 2012 at 11:03 PM, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@**erdani.org<SeeWebsiteForEmail@erdani.org>
>> >>
>>
>> wrote:
>>
>>     On 7/13/12 2:30 PM, Gor Gyolchanyan wrote:
>>
>>         The whole point is to have it not static. I need it to be properly
>>         nested with the this.outer.
>>
>>
>>     What would be the type of this.outer?
>>
>>     Andrei
>>
>>
>> For Fruit.Seed it's Fruit, for AppleSeed it's Apple. This makes sense because the Apple, which AppleSeed sees is the same object, which Fruit.Seed sees as it's base type Fruit.
>>
>
> That would mean AppleSeed has two outer fields: a Fruit and an Apple.
>
> Andrei
>
>
Why? The this.outer would be the same object from both perspectives. The difference is, that the Fruit.Seed would see it as Fruit and the AppleSeed would see it as Apple. And If someone derived from Apple and AppleSeed (say RedAple and RedAppleSeed), the RedAppleSeed would see the exact same object, except typed as RedApple.

When you create a new AppleSeed, you need to create it from an Apple or something derived from an Apple. This ensures, that every seed sees the correct fruit as the correct type.

-- 
Bye,
Gor Gyolchanyan.


July 13, 2012
On Fri, Jul 13, 2012 at 11:18 PM, Christophe Travert < travert@phare.normalesup.org> wrote:

> Andrei Alexandrescu , dans le message (digitalmars.D:172280), a écrit :
> >> For Fruit.Seed it's Fruit, for AppleSeed it's Apple. This makes sense because the Apple, which AppleSeed sees is the same object, which Fruit.Seed sees as it's base type Fruit.
> >
> > That would mean AppleSeed has two outer fields: a Fruit and an Apple.
>
> Only one. Apple. And when AppleSeed.super seed this Apple, it sees a fruit.
>
> AppleSeed a;
> assert(is(typeof(a.outer) == Apple));
> assert(is(typeof(a.super) == Seed));
> assert(is(typeof(a.super.outer) == Fruit));
> //but:
> assert(a.outer is a.super.outer);
>
> If you can't figure out how can a.outer and a.super.outer have two different types, but be the same, think about covariant return.
>
>
>
Exactly!

-- 
Bye,
Gor Gyolchanyan.


July 13, 2012
On Friday, 13 July 2012 at 19:08:54 UTC, Gor Gyolchanyan wrote:

>> If you make seed static, then Appleseed & apple will have access to Fruit but seed (by itself) won't. Other combinations faile as far as I can tell. How far you can take inner class inheritance I don't know, but it seems not that many levels.
>
> This all won't work, because having Fruit know about Apple defeats the
> whole purpose.

So why not...??

class Seed{} //same as static class in fruit

class Apple {
  class Appleseed : Seed {}
}

 Perhaps you would rather have Seed as an interface instead? It seems like I need a full detail of how everything connects together, so let's see..

 Fruit covers apple (but maybe not seed)
 Apple covers (and is a class of) fruit, but also contains a seed (or the seed pertains to Apple specifically)
 All fruits (including apple's) have seeds that do specific things, namely plant, water and grow, and perhaps produceFruit.

 If that isn't right, explain how the relationship of it all goes and a possible solution may show itself.
July 13, 2012
On 7/13/12 3:18 PM, Christophe Travert wrote:
> Andrei Alexandrescu , dans le message (digitalmars.D:172280), a écrit :
>>> For Fruit.Seed it's Fruit, for AppleSeed it's Apple. This makes sense
>>> because the Apple, which AppleSeed sees is the same object, which
>>> Fruit.Seed sees as it's base type Fruit.
>>
>> That would mean AppleSeed has two outer fields: a Fruit and an Apple.
>
> Only one. Apple. And when AppleSeed.super seed this Apple, it sees a
> fruit.
>
> AppleSeed a;
> assert(is(typeof(a.outer) == Apple));
> assert(is(typeof(a.super) == Seed));
> assert(is(typeof(a.super.outer) == Fruit));
> //but:
> assert(a.outer is a.super.outer);
>
> If you can't figure out how can a.outer and a.super.outer have two
> different types, but be the same, think about covariant return.

Makes sense, thanks.

Andrei

July 13, 2012
On Fri, Jul 13, 2012 at 11:26 PM, Era Scarecrow <rtcvb32@yahoo.com> wrote:

> On Friday, 13 July 2012 at 19:08:54 UTC, Gor Gyolchanyan wrote:
>
>  If you make seed static, then Appleseed & apple will have access to Fruit
>>> but seed (by itself) won't. Other combinations faile as far as I can tell. How far you can take inner class inheritance I don't know, but it seems not that many levels.
>>>
>>
>> This all won't work, because having Fruit know about Apple defeats the whole purpose.
>>
>
> So why not...??
>
> class Seed{} //same as static class in fruit
>
>
> class Apple {
>   class Appleseed : Seed {}
> }
>
>  Perhaps you would rather have Seed as an interface instead? It seems like
> I need a full detail of how everything connects together, so let's see..
>
>  Fruit covers apple (but maybe not seed)
>  Apple covers (and is a class of) fruit, but also contains a seed (or the
> seed pertains to Apple specifically)
>  All fruits (including apple's) have seeds that do specific things, namely
> plant, water and grow, and perhaps produceFruit.
>
>  If that isn't right, explain how the relationship of it all goes and a
> possible solution may show itself.
>

The seed can't be an interface because it needs to contain state. For instance the progress towards becoming the respective fruit.

The seed needs to be aware of the fruit it came from to access the fruit's DNA to inherit the traits of that fruit when it grows into a fruit of its own. (Please note, that it's just an example).

A fruit can have multiple such seeds, each of which must have it's own state and connection to the same fruit they came from.

So, we start off by inheriting from Fruit, defining the properties of that fruit (It's an Apple, it's delicious and it goes great in a pie). Then we define several different types of Apple seeds, each of which need access to the apple.

-- 
Bye,
Gor Gyolchanyan.