www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - nested class inheritance

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Doesn't this make sense?

class Fruit
{
    class Seed { }
}

class Apple: Fruit
{
     class AppleSeed: Fruit.Seed { }
}

This means, that as Fruit.Seed needs access to enclosing Fruit, AppleSeed,
being a Fruit.Seed will also have access to enclosing Fruit, which is Apple.
DMD 0.259 has this to say:

Error: class main.Apple.AppleSeed is nested within Apple, but super class
Seed is nested within Fruit

Which doesn't make sense, IMO. What do you guys think about this? Who makes
more sense me or DMD 2.059?

-- 
Bye,
Gor Gyolchanyan.
Jul 13 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/13/12 1:59 PM, Gor Gyolchanyan wrote:

 Doesn't this make sense?

 class Fruit
 {
      class Seed { }
 }

 class Apple: Fruit
 {
       class AppleSeed: Fruit.Seed { }
 }

 This means, that as Fruit.Seed needs access to enclosing Fruit,
 AppleSeed, being a Fruit.Seed will also have access to enclosing Fruit,
 which is Apple.
 DMD 0.259 has this to say:

 Error: class main.Apple.AppleSeed is nested within Apple, but super
 class Seed is nested within Fruit

 Which doesn't make sense, IMO. What do you guys think about this? Who
 makes more sense me or DMD 2.059?


Untested:

class Fruit
{
     static class Seed { }
}

class Apple: Fruit
{
      static class AppleSeed: Fruit.Seed { }
}


Andrei
Jul 13 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
On Fri, Jul 13, 2012 at 10:19 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 7/13/12 1:59 PM, Gor Gyolchanyan wrote:


 Doesn't this make sense?

 class Fruit
 {
      class Seed { }
 }

 class Apple: Fruit
 {
       class AppleSeed: Fruit.Seed { }
 }

 This means, that as Fruit.Seed needs access to enclosing Fruit,
 AppleSeed, being a Fruit.Seed will also have access to enclosing Fruit,
 which is Apple.
 DMD 0.259 has this to say:

 Error: class main.Apple.AppleSeed is nested within Apple, but super
 class Seed is nested within Fruit

 Which doesn't make sense, IMO. What do you guys think about this? Who
 makes more sense me or DMD 2.059?


 Untested:

 class Fruit
 {
     static class Seed { }
 }

 class Apple: Fruit
 {
      static class AppleSeed: Fruit.Seed { }
 }


 Andrei


The whole point is to have it not static. I need it to be properly nested
with the this.outer.

-- 
Bye,
Gor Gyolchanyan.
Jul 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 13 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.
Jul 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 13 2012
next sibling parent reply travert phare.normalesup.org (Christophe Travert) writes:
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.
Jul 13 2012
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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 =C3=A9cri=


t :

 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) =3D=3D Apple));
 assert(is(typeof(a.super) =3D=3D Seed));
 assert(is(typeof(a.super.outer) =3D=3D 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!

--=20
Bye,
Gor Gyolchanyan.
Jul 13 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 13 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
On Fri, Jul 13, 2012 at 11:30 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 7/13/12 3:18 PM, Christophe Travert wrote:


 Andrei Alexandrescu , dans le message (digitalmars.D:172280), a =C3=A9cr=




it :

 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) =3D=3D Apple));
 assert(is(typeof(a.super) =3D=3D Seed));
 assert(is(typeof(a.super.**outer) =3D=3D 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


The initial question was: why does DMD 2.059 reject this if this makes
sense?
It's not even a new feature. It's a (possibly) new (and apparently
sensible) use case of an existing feature.

I came up with this when I was trying to work around the limitation of not
having multiple inheritance.

--=20
Bye,
Gor Gyolchanyan.
Jul 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/13/12 3:36 PM, Gor Gyolchanyan wrote:

 The initial question was: why does DMD 2.059 reject this if this makes
 sense?
 It's not even a new feature. It's a (possibly) new (and apparently
 sensible) use case of an existing feature.


I think the simple answer is there was no provision for it. The feature 
copies the Java feature, and I don't think Java has something like what 
you defined.

Andrei
Jul 13 2012
next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
On Fri, Jul 13, 2012 at 11:41 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 7/13/12 3:36 PM, Gor Gyolchanyan wrote:


 The initial question was: why does DMD 2.059 reject this if this makes
 sense?
 It's not even a new feature. It's a (possibly) new (and apparently
 sensible) use case of an existing feature.


 I think the simple answer is there was no provision for it. The feature
 copies the Java feature, and I don't think Java has something like what you
 defined.

 Andrei


Well, the nested classes are pretty much useless without this feature.
Except for translating Java code. If I had multiple inheritance, I'd just
make the Apple as base class and have all the seeds virtually derive from
it. Not having multiple inheritance drove me to try the next best think.
And after it failed, I complained about it. And here we are. Is it a
difficult thing to fix?

-- 
Bye,
Gor Gyolchanyan.
Jul 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/13/12 3:49 PM, Gor Gyolchanyan wrote:

 On Fri, Jul 13, 2012 at 11:41 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>
 wrote:

     On 7/13/12 3:36 PM, Gor Gyolchanyan wrote:

         The initial question was: why does DMD 2.059 reject this if this
         makes
         sense?
         It's not even a new feature. It's a (possibly) new (and apparently
         sensible) use case of an existing feature.


     I think the simple answer is there was no provision for it. The
     feature copies the Java feature, and I don't think Java has
     something like what you defined.

     Andrei


 Well, the nested classes are pretty much useless without this feature.
 Except for translating Java code. If I had multiple inheritance, I'd
 just make the Apple as base class and have all the seeds virtually
 derive from it. Not having multiple inheritance drove me to try the next
 best think. And after it failed, I complained about it.. And here we
 are. Is it a difficult thing to fix?


I don't know, you may want to submit an enhancement request.

Andrei
Jul 13 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
On Sat, Jul 14, 2012 at 12:31 AM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 7/13/12 3:49 PM, Gor Gyolchanyan wrote:


 On Fri, Jul 13, 2012 at 11:41 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org
<mailto:SeeWebsiteForEmail **erdani.org<SeeWebsiteForEmail erdani.org>




 wrote:

     On 7/13/12 3:36 PM, Gor Gyolchanyan wrote:

         The initial question was: why does DMD 2.059 reject this if this
         makes
         sense?
         It's not even a new feature. It's a (possibly) new (and apparently
         sensible) use case of an existing feature.


     I think the simple answer is there was no provision for it. The
     feature copies the Java feature, and I don't think Java has
     something like what you defined.

     Andrei


 Well, the nested classes are pretty much useless without this feature.
 Except for translating Java code. If I had multiple inheritance, I'd
 just make the Apple as base class and have all the seeds virtually
 derive from it. Not having multiple inheritance drove me to try the next
 best think. And after it failed, I complained about it.. And here we

 are. Is it a difficult thing to fix?


 I don't know, you may want to submit an enhancement request.

 Andrei


http://d.puremagic.com/issues/show_bug.cgi?id=8389

Anyone who thinks this is important, please vote up.

-- 
Bye,
Gor Gyolchanyan.



 Jul 13 2012



  parent reply deadalnix <deadalnix gmail.com>  writes:


On 14/07/2012 08:27, Gor Gyolchanyan wrote:

 On Sat, Jul 14, 2012 at 12:31 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>
 wrote:

     On 7/13/12 3:49 PM, Gor Gyolchanyan wrote:

         On Fri, Jul 13, 2012 at 11:41 PM, Andrei Alexandrescu
         <SeeWebsiteForEmail erdani.org
         <mailto:SeeWebsiteForEmail erdani.org>
         <mailto:SeeWebsiteForEmail __erdani.org
         <mailto:SeeWebsiteForEmail erdani.org>>>

         wrote:

              On 7/13/12 3:36 PM, Gor Gyolchanyan wrote:

                  The initial question was: why does DMD 2.059 reject
         this if this
                  makes
                  sense?
                  It's not even a new feature. It's a (possibly) new (and
         apparently
                  sensible) use case of an existing feature.


              I think the simple answer is there was no provision for it. The
              feature copies the Java feature, and I don't think Java has
              something like what you defined.

              Andrei


         Well, the nested classes are pretty much useless without this
         feature.
         Except for translating Java code. If I had multiple inheritance, I'd
         just make the Apple as base class and have all the seeds virtually
         derive from it. Not having multiple inheritance drove me to try
         the next
         best think. And after it failed, I complained about it.. And here we

         are. Is it a difficult thing to fix?


     I don't know, you may want to submit an enhancement request.

     Andrei


 http://d.puremagic.com/issues/show_bug.cgi?id=8389

 Anyone who thinks this is important, please vote up.

 --
 Bye,
 Gor Gyolchanyan.


This is something to do, but I don't know if it is really that important.



 Jul 14 2012



  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sat, Jul 14, 2012 at 8:17 PM, deadalnix <deadalnix gmail.com> wrote:


 On 14/07/2012 08:27, Gor Gyolchanyan wrote:


 On Sat, Jul 14, 2012 at 12:31 AM, Andrei Alexandrescu

 <SeeWebsiteForEmail erdani.org
<mailto:SeeWebsiteForEmail **erdani.org<SeeWebsiteForEmail erdani.org>




 wrote:

     On 7/13/12 3:49 PM, Gor Gyolchanyan wrote:

         On Fri, Jul 13, 2012 at 11:41 PM, Andrei Alexandrescu
         <SeeWebsiteForEmail erdani.org
         <mailto:SeeWebsiteForEmail **erdani.org<SeeWebsiteForEmail erdani.org>


         <mailto:SeeWebsiteForEmail __e**rdani.org <http://erdani.org>

         <mailto:SeeWebsiteForEmail **erdani.org<SeeWebsiteForEmail erdani.org>






         wrote:

              On 7/13/12 3:36 PM, Gor Gyolchanyan wrote:

                  The initial question was: why does DMD 2.059 reject
         this if this
                  makes
                  sense?
                  It's not even a new feature. It's a (possibly) new (and
         apparently
                  sensible) use case of an existing feature.


              I think the simple answer is there was no provision for it.
 The
              feature copies the Java feature, and I don't think Java has
              something like what you defined.

              Andrei


         Well, the nested classes are pretty much useless without this
         feature.
         Except for translating Java code. If I had multiple inheritance,
 I'd
         just make the Apple as base class and have all the seeds virtually
         derive from it. Not having multiple inheritance drove me to try
         the next
         best think. And after it failed, I complained about it.. And here
 we

         are. Is it a difficult thing to fix?


     I don't know, you may want to submit an enhancement request.

     Andrei


 http://d.puremagic.com/issues/**show_bug.cgi?id=8389<http://d.puremagic.com/issues/show_bug.cgi?id=8389>

 Anyone who thinks this is important, please vote up.

 --
 Bye,
 Gor Gyolchanyan.


 This is something to do, but I don't know if it is really that important.


It's already fixed and will be in DMD 2.060

-- 
Bye,
Gor Gyolchanyan.



 Jul 14 2012



  parent reply Benjamin Thaut <code benjamin-thaut.de>  writes:


The only problem about this is:

class Fruit
{
   class Seed {
     void SetFruit(Fruit fruit)
     {
       this.outer = fruit;
     }
   }
}

class Apple: Fruit
{
   void AppleOnlyMethod(){ ... }

   class AppleSeed: Fruit.Seed {
     void DoSomething()
     {
       AppleOnlyMethod();
     }
   }

   auto GetNewSeed() { return new AppleSeed(); }
}

auto apple = new Apple();
auto seed = apple.GetNewSeed();
seed.SetFruit(new Fruit());
seed.DoSomething(); //what happens here?

Kind Regards
Benjamin Thaut



 Jul 14 2012



 next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sat, Jul 14, 2012 at 9:12 PM, Benjamin Thaut <code benjamin-thaut.de>wrote:


 The only problem about this is:

 class Fruit
 {
   class Seed {
     void SetFruit(Fruit fruit)
     {
       this.outer = fruit;
     }
   }
 }

 class Apple: Fruit
 {
   void AppleOnlyMethod(){ ... }

   class AppleSeed: Fruit.Seed {
     void DoSomething()
     {
       AppleOnlyMethod();
     }
   }

   auto GetNewSeed() { return new AppleSeed(); }
 }

 auto apple = new Apple();
 auto seed = apple.GetNewSeed();
 seed.SetFruit(new Fruit());
 seed.DoSomething(); //what happens here?

 Kind Regards
 Benjamin Thaut


I think this.outer is not an lvalue, which solves the problem. It wouldn't
make sense to have it an lvalue, because the object is specifically created
out of the initial outer object.

-- 
Bye,
Gor Gyolchanyan.



 Jul 14 2012



  parent  Benjamin Thaut <code benjamin-thaut.de>  writes:


Am 14.07.2012 19:18, schrieb Gor Gyolchanyan:

 On Sat, Jul 14, 2012 at 9:12 PM, Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de>> wrote:

     The only problem about this is:

     class Fruit
     {
        class Seed {
          void SetFruit(Fruit fruit)
          {
            this.outer = fruit;
          }
        }
     }

     class Apple: Fruit
     {
        void AppleOnlyMethod(){ ... }

        class AppleSeed: Fruit.Seed {
          void DoSomething()
          {
            AppleOnlyMethod();
          }
        }

        auto GetNewSeed() { return new AppleSeed(); }
     }

     auto apple = new Apple();
     auto seed = apple.GetNewSeed();
     seed.SetFruit(new Fruit());
     seed.DoSomething(); //what happens here?

     Kind Regards
     Benjamin Thaut


 I think this.outer is not an lvalue, which solves the problem. It
 wouldn't make sense to have it an lvalue, because the object is
 specifically created out of the initial outer object.

 --
 Bye,
 Gor Gyolchanyan.


The last time I checked you could reassign outer ;-)



 Jul 14 2012



prev sibling  parent reply kenji hara <k.hara.pg gmail.com>  writes:


2012/7/15 Benjamin Thaut <code benjamin-thaut.de>:

 The only problem about this is:

 class Fruit
 {
   class Seed {
     void SetFruit(Fruit fruit)
     {
       this.outer = fruit;


Setting to pseudo variable 'outer' should be rejected in compilation.
Please report it to bugzilla.


     }
   }
 }

 class Apple: Fruit
 {
   void AppleOnlyMethod(){ ... }

   class AppleSeed: Fruit.Seed {
     void DoSomething()
     {
       AppleOnlyMethod();
     }
   }

   auto GetNewSeed() { return new AppleSeed(); }
 }

 auto apple = new Apple();
 auto seed = apple.GetNewSeed();
 seed.SetFruit(new Fruit());
 seed.DoSomething(); //what happens here?

 Kind Regards
 Benjamin Thaut


Kenji Hara



 Jul 14 2012



  parent reply Benjamin Thaut <code benjamin-thaut.de>  writes:


Am 14.07.2012 19:21, schrieb kenji hara:

 2012/7/15 Benjamin Thaut <code benjamin-thaut.de>:

 The only problem about this is:

 class Fruit
 {
    class Seed {
      void SetFruit(Fruit fruit)
      {
        this.outer = fruit;


 Setting to pseudo variable 'outer' should be rejected in compilation.
 Please report it to bugzilla.


      }
    }
 }

 class Apple: Fruit
 {
    void AppleOnlyMethod(){ ... }

    class AppleSeed: Fruit.Seed {
      void DoSomething()
      {
        AppleOnlyMethod();
      }
    }

    auto GetNewSeed() { return new AppleSeed(); }
 }

 auto apple = new Apple();
 auto seed = apple.GetNewSeed();
 seed.SetFruit(new Fruit());
 seed.DoSomething(); //what happens here?

 Kind Regards
 Benjamin Thaut


 Kenji Hara


I will not report this, beacuse it will break my custom new operator 
(template) for inner classes ;-)

Kind Regards
Benjamin Thaut



 Jul 14 2012



  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code benjamin-thaut.de>wrote:


 Am 14.07.2012 19:21, schrieb kenji hara:


 2012/7/15 Benjamin Thaut <code benjamin-thaut.de>:

  The only problem about this is:

 class Fruit
 {
    class Seed {
      void SetFruit(Fruit fruit)
      {
        this.outer = fruit;


 Setting to pseudo variable 'outer' should be rejected in compilation.
 Please report it to bugzilla.

       }

    }
 }

 class Apple: Fruit
 {
    void AppleOnlyMethod(){ ... }

    class AppleSeed: Fruit.Seed {
      void DoSomething()
      {
        AppleOnlyMethod();
      }
    }

    auto GetNewSeed() { return new AppleSeed(); }
 }

 auto apple = new Apple();
 auto seed = apple.GetNewSeed();
 seed.SetFruit(new Fruit());
 seed.DoSomething(); //what happens here?

 Kind Regards
 Benjamin Thaut


 Kenji Hara


 I will not report this, beacuse it will break my custom new operator
 (template) for inner classes ;-)

 Kind Regards
 Benjamin Thaut


That's most unwise, because if it's not supposed to be like that it will
get fixed anyway, so you better start replacing your custom new operator.

-- 
Bye,
Gor Gyolchanyan.



 Jul 14 2012



  parent reply Benjamin Thaut <code benjamin-thaut.de>  writes:


Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:

 On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de>> wrote:

     Am 14.07.2012 19:21, schrieb kenji hara:

         2012/7/15 Benjamin Thaut <code benjamin-thaut.de
         <mailto:code benjamin-thaut.de>>:

             The only problem about this is:

             class Fruit
             {
                 class Seed {
                   void SetFruit(Fruit fruit)
                   {
                     this.outer = fruit;


         Setting to pseudo variable 'outer' should be rejected in
         compilation.
         Please report it to bugzilla.

                   }
                 }
             }

             class Apple: Fruit
             {
                 void AppleOnlyMethod(){ ... }

                 class AppleSeed: Fruit.Seed {
                   void DoSomething()
                   {
                     AppleOnlyMethod();
                   }
                 }

                 auto GetNewSeed() { return new AppleSeed(); }
             }

             auto apple = new Apple();
             auto seed = apple.GetNewSeed();
             seed.SetFruit(new Fruit());
             seed.DoSomething(); //what happens here?

             Kind Regards
             Benjamin Thaut


         Kenji Hara


     I will not report this, beacuse it will break my custom new operator
     (template) for inner classes ;-)

     Kind Regards
     Benjamin Thaut


 That's most unwise, because if it's not supposed to be like that it will
 get fixed anyway, so you better start replacing your custom new operator.

 --
 Bye,
 Gor Gyolchanyan.


Replacing my custom new operator exactly by what? Overloading the build 
in new is deprecated...



 Jul 14 2012



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/15/2012 12:55 AM, Benjamin Thaut wrote:

 Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:

 On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de>> wrote:

 Am 14.07.2012 19:21, schrieb kenji hara:

 2012/7/15 Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de>>:

 The only problem about this is:

 class Fruit
 {
 class Seed {
 void SetFruit(Fruit fruit)
 {
 this.outer = fruit;


 Setting to pseudo variable 'outer' should be rejected in
 compilation.
 Please report it to bugzilla.

 }
 }
 }

 class Apple: Fruit
 {
 void AppleOnlyMethod(){ ... }

 class AppleSeed: Fruit.Seed {
 void DoSomething()
 {
 AppleOnlyMethod();
 }
 }

 auto GetNewSeed() { return new AppleSeed(); }
 }

 auto apple = new Apple();
 auto seed = apple.GetNewSeed();
 seed.SetFruit(new Fruit());
 seed.DoSomething(); //what happens here?

 Kind Regards
 Benjamin Thaut


 Kenji Hara


 I will not report this, beacuse it will break my custom new operator
 (template) for inner classes ;-)

 Kind Regards
 Benjamin Thaut


 That's most unwise, because if it's not supposed to be like that it will
 get fixed anyway, so you better start replacing your custom new operator.

 --
 Bye,
 Gor Gyolchanyan.


 Replacing my custom new operator exactly by what? Overloading the build
 in new is deprecated...


class C{
     class D{

     }
}
void main(){
     auto c = new C;
     auto buf = new void[__traits(classInstanceSize, C.D)];
     (cast(byte[])buf)[] = typeid(C.D).init[];
     auto d = cast(C.D)buf.ptr;
     static if(is(typeof(d.__ctor()))) d.__ctor();
     enum offset=d.outer.offsetof;
     static assert(offset%C.sizeof==0);
     (cast(C[])buf)[offset/C.sizeof]=c;
     assert(d.outer is c);
}



 Jul 14 2012



  parent reply Benjamin Thaut <code benjamin-thaut.de>  writes:


Am 15.07.2012 02:02, schrieb Timon Gehr:

 On 07/15/2012 12:55 AM, Benjamin Thaut wrote:

 Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:

 On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de>> wrote:

 Am 14.07.2012 19:21, schrieb kenji hara:

 2012/7/15 Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de>>:

 The only problem about this is:

 class Fruit
 {
 class Seed {
 void SetFruit(Fruit fruit)
 {
 this.outer = fruit;


 Setting to pseudo variable 'outer' should be rejected in
 compilation.
 Please report it to bugzilla.

 }
 }
 }

 class Apple: Fruit
 {
 void AppleOnlyMethod(){ ... }

 class AppleSeed: Fruit.Seed {
 void DoSomething()
 {
 AppleOnlyMethod();
 }
 }

 auto GetNewSeed() { return new AppleSeed(); }
 }

 auto apple = new Apple();
 auto seed = apple.GetNewSeed();
 seed.SetFruit(new Fruit());
 seed.DoSomething(); //what happens here?

 Kind Regards
 Benjamin Thaut


 Kenji Hara


 I will not report this, beacuse it will break my custom new operator
 (template) for inner classes ;-)

 Kind Regards
 Benjamin Thaut


 That's most unwise, because if it's not supposed to be like that it will
 get fixed anyway, so you better start replacing your custom new
 operator.

 --
 Bye,
 Gor Gyolchanyan.


 Replacing my custom new operator exactly by what? Overloading the build
 in new is deprecated...


 class C{
      class D{

      }
 }
 void main(){
      auto c = new C;
      auto buf = new void[__traits(classInstanceSize, C.D)];
      (cast(byte[])buf)[] = typeid(C.D).init[];
      auto d = cast(C.D)buf.ptr;
      static if(is(typeof(d.__ctor()))) d.__ctor();
      enum offset=d.outer.offsetof;
      static assert(offset%C.sizeof==0);
      (cast(C[])buf)[offset/C.sizeof]=c;
      assert(d.outer is c);
 }


Yes of course I can assign the reference by computing the address and 
then using that to assign it. But the point here is, that this is 
currently the only bug that is hepling me in what I'm doing, and I 
rather want the 7 other bugs I reported so far to be fixed, rather then 
the one that helps me.

Kind Regards
Benjamin Thaut



 Jul 15 2012



 next sibling parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sun, Jul 15, 2012 at 1:41 PM, Benjamin Thaut <code benjamin-thaut.de>wrote:


 Am 15.07.2012 02:02, schrieb Timon Gehr:

  On 07/15/2012 12:55 AM, Benjamin Thaut wrote:

 Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:


 On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de**>> wrote:

 Am 14.07.2012 19:21, schrieb kenji hara:

 2012/7/15 Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de**>>:

 The only problem about this is:

 class Fruit
 {
 class Seed {
 void SetFruit(Fruit fruit)
 {
 this.outer = fruit;


 Setting to pseudo variable 'outer' should be rejected in
 compilation.
 Please report it to bugzilla.

 }
 }
 }

 class Apple: Fruit
 {
 void AppleOnlyMethod(){ ... }

 class AppleSeed: Fruit.Seed {
 void DoSomething()
 {
 AppleOnlyMethod();
 }
 }

 auto GetNewSeed() { return new AppleSeed(); }
 }

 auto apple = new Apple();
 auto seed = apple.GetNewSeed();
 seed.SetFruit(new Fruit());
 seed.DoSomething(); //what happens here?

 Kind Regards
 Benjamin Thaut


 Kenji Hara


 I will not report this, beacuse it will break my custom new operator
 (template) for inner classes ;-)

 Kind Regards
 Benjamin Thaut


 That's most unwise, because if it's not supposed to be like that it will
 get fixed anyway, so you better start replacing your custom new
 operator.

 --
 Bye,
 Gor Gyolchanyan.


 Replacing my custom new operator exactly by what? Overloading the build
 in new is deprecated...


 class C{
      class D{

      }
 }
 void main(){
      auto c = new C;
      auto buf = new void[__traits(**classInstanceSize, C.D)];
      (cast(byte[])buf)[] = typeid(C.D).init[];
      auto d = cast(C.D)buf.ptr;
      static if(is(typeof(d.__ctor()))) d.__ctor();
      enum offset=d.outer.offsetof;
      static assert(offset%C.sizeof==0);
      (cast(C[])buf)[offset/C.**sizeof]=c;
      assert(d.outer is c);
 }


 Yes of course I can assign the reference by computing the address and then
 using that to assign it. But the point here is, that this is currently the
 only bug that is hepling me in what I'm doing, and I rather want the 7
 other bugs I reported so far to be fixed, rather then the one that helps me.

 Kind Regards
 Benjamin Thaut


Don't you understand? It doesn't matter how much a bug helps you (or
anything else for that matter) if it's a bug - it's gonna be fixed. If you
decided to abuse a bug - it's your problem and your problem alone. The
earlier you start getting rid of that design, the easier it will be when
the bug gets inevitable fixed.

-- 
Bye,
Gor Gyolchanyan.



 Jul 15 2012



prev sibling  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sun, Jul 15, 2012 at 1:41 PM, Benjamin Thaut <code benjamin-thaut.de>wrote:


 Am 15.07.2012 02:02, schrieb Timon Gehr:

  On 07/15/2012 12:55 AM, Benjamin Thaut wrote:

 Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:


 On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de**>> wrote:

 Am 14.07.2012 19:21, schrieb kenji hara:

 2012/7/15 Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de**>>:

 The only problem about this is:

 class Fruit
 {
 class Seed {
 void SetFruit(Fruit fruit)
 {
 this.outer = fruit;


 Setting to pseudo variable 'outer' should be rejected in
 compilation.
 Please report it to bugzilla.

 }
 }
 }

 class Apple: Fruit
 {
 void AppleOnlyMethod(){ ... }

 class AppleSeed: Fruit.Seed {
 void DoSomething()
 {
 AppleOnlyMethod();
 }
 }

 auto GetNewSeed() { return new AppleSeed(); }
 }

 auto apple = new Apple();
 auto seed = apple.GetNewSeed();
 seed.SetFruit(new Fruit());
 seed.DoSomething(); //what happens here?

 Kind Regards
 Benjamin Thaut


 Kenji Hara


 I will not report this, beacuse it will break my custom new operator
 (template) for inner classes ;-)

 Kind Regards
 Benjamin Thaut


 That's most unwise, because if it's not supposed to be like that it will
 get fixed anyway, so you better start replacing your custom new
 operator.

 --
 Bye,
 Gor Gyolchanyan.


 Replacing my custom new operator exactly by what? Overloading the build
 in new is deprecated...


 class C{
      class D{

      }
 }
 void main(){
      auto c = new C;
      auto buf = new void[__traits(**classInstanceSize, C.D)];
      (cast(byte[])buf)[] = typeid(C.D).init[];
      auto d = cast(C.D)buf.ptr;
      static if(is(typeof(d.__ctor()))) d.__ctor();
      enum offset=d.outer.offsetof;
      static assert(offset%C.sizeof==0);
      (cast(C[])buf)[offset/C.**sizeof]=c;
      assert(d.outer is c);
 }


 Yes of course I can assign the reference by computing the address and then
 using that to assign it. But the point here is, that this is currently the
 only bug that is hepling me in what I'm doing, and I rather want the 7
 other bugs I reported so far to be fixed, rather then the one that helps me.

 Kind Regards
 Benjamin Thaut


Not being able to assign is not about some sort of authoritative
forbidding. It's about not breaking a working mechanism. You can't cast a
function pointer into a class object not because the type system says so
(which it does), but because that'll result in an undefined behavior, which
will result in an immediate crash in the best scenario. Go ahead and change
the outer via those hacks. But then don't get surprised when your program
crashes for no reason (because the compiler assumed it not to change and
ended up being wrong).

-- 
Bye,
Gor Gyolchanyan.



 Jul 15 2012



  parent reply Benjamin Thaut <code benjamin-thaut.de>  writes:


Am 15.07.2012 13:24, schrieb Gor Gyolchanyan:

 On Sun, Jul 15, 2012 at 1:41 PM, Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de>> wrote:

     Am 15.07.2012 02:02, schrieb Timon Gehr:

         On 07/15/2012 12:55 AM, Benjamin Thaut wrote:

             Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:

                 On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut
                 <code benjamin-thaut.de <mailto:code benjamin-thaut.de>
                 <mailto:code benjamin-thaut.de
                 <mailto:code benjamin-thaut.de>__>> wrote:

                 Am 14.07.2012 19:21, schrieb kenji hara:

                 2012/7/15 Benjamin Thaut <code benjamin-thaut.de
                 <mailto:code benjamin-thaut.de>
                 <mailto:code benjamin-thaut.de
                 <mailto:code benjamin-thaut.de>__>>:

                 The only problem about this is:

                 class Fruit
                 {
                 class Seed {
                 void SetFruit(Fruit fruit)
                 {
                 this.outer = fruit;


                 Setting to pseudo variable 'outer' should be rejected in
                 compilation.
                 Please report it to bugzilla.

                 }
                 }
                 }

                 class Apple: Fruit
                 {
                 void AppleOnlyMethod(){ ... }

                 class AppleSeed: Fruit.Seed {
                 void DoSomething()
                 {
                 AppleOnlyMethod();
                 }
                 }

                 auto GetNewSeed() { return new AppleSeed(); }
                 }

                 auto apple = new Apple();
                 auto seed = apple.GetNewSeed();
                 seed.SetFruit(new Fruit());
                 seed.DoSomething(); //what happens here?

                 Kind Regards
                 Benjamin Thaut


                 Kenji Hara


                 I will not report this, beacuse it will break my custom
                 new operator
                 (template) for inner classes ;-)

                 Kind Regards
                 Benjamin Thaut


                 That's most unwise, because if it's not supposed to be
                 like that it will
                 get fixed anyway, so you better start replacing your
                 custom new
                 operator.

                 --
                 Bye,
                 Gor Gyolchanyan.


             Replacing my custom new operator exactly by what?
             Overloading the build
             in new is deprecated...


         class C{
               class D{

               }
         }
         void main(){
               auto c = new C;
               auto buf = new void[__traits(__classInstanceSize, C.D)];
               (cast(byte[])buf)[] = typeid(C.D).init[];
               auto d = cast(C.D)buf.ptr;
               static if(is(typeof(d.__ctor()))) d.__ctor();
               enum offset=d.outer.offsetof;
               static assert(offset%C.sizeof==0);
               (cast(C[])buf)[offset/C.__sizeof]=c;
               assert(d.outer is c);
         }


     Yes of course I can assign the reference by computing the address
     and then using that to assign it. But the point here is, that this
     is currently the only bug that is hepling me in what I'm doing, and
     I rather want the 7 other bugs I reported so far to be fixed, rather
     then the one that helps me.

     Kind Regards
     Benjamin Thaut


 Not being able to assign is not about some sort of authoritative
 forbidding. It's about not breaking a working mechanism. You can't cast
 a function pointer into a class object not because the type system says
 so (which it does), but because that'll result in an undefined behavior,
 which will result in an immediate crash in the best scenario. Go ahead
 and change the outer via those hacks. But then don't get surprised when
 your program crashes for no reason (because the compiler assumed it not
 to change and ended up being wrong).

 --
 Bye,
 Gor Gyolchanyan.


Before your change suggestion it was absolutley save to assign to outer. 
Thats the whole point why I posted this here. I very well know that the 
bug will get fixed some time. But before your change suggestion it was 
not even a bug.

Kind Regards
Benjamin Thaut



 Jul 15 2012



  parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sun, Jul 15, 2012 at 3:35 PM, Benjamin Thaut <code benjamin-thaut.de>wrote:


 Am 15.07.2012 13:24, schrieb Gor Gyolchanyan:


 On Sun, Jul 15, 2012 at 1:41 PM, Benjamin Thaut <code benjamin-thaut.de

 <mailto:code benjamin-thaut.de**>> wrote:

     Am 15.07.2012 02:02, schrieb Timon Gehr:

         On 07/15/2012 12:55 AM, Benjamin Thaut wrote:

             Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:

                 On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut
                 <code benjamin-thaut.de <mailto:code benjamin-thaut.de**>
                 <mailto:code benjamin-thaut.de

                 <mailto:code benjamin-thaut.de**>__>> wrote:

                 Am 14.07.2012 19:21, schrieb kenji hara:

                 2012/7/15 Benjamin Thaut <code benjamin-thaut.de
                 <mailto:code benjamin-thaut.de**>
                 <mailto:code benjamin-thaut.de
                 <mailto:code benjamin-thaut.de**>__>>:


                 The only problem about this is:

                 class Fruit
                 {
                 class Seed {
                 void SetFruit(Fruit fruit)
                 {
                 this.outer = fruit;


                 Setting to pseudo variable 'outer' should be rejected in
                 compilation.
                 Please report it to bugzilla.

                 }
                 }
                 }

                 class Apple: Fruit
                 {
                 void AppleOnlyMethod(){ ... }

                 class AppleSeed: Fruit.Seed {
                 void DoSomething()
                 {
                 AppleOnlyMethod();
                 }
                 }

                 auto GetNewSeed() { return new AppleSeed(); }
                 }

                 auto apple = new Apple();
                 auto seed = apple.GetNewSeed();
                 seed.SetFruit(new Fruit());
                 seed.DoSomething(); //what happens here?

                 Kind Regards
                 Benjamin Thaut


                 Kenji Hara


                 I will not report this, beacuse it will break my custom
                 new operator
                 (template) for inner classes ;-)

                 Kind Regards
                 Benjamin Thaut


                 That's most unwise, because if it's not supposed to be
                 like that it will
                 get fixed anyway, so you better start replacing your
                 custom new
                 operator.

                 --
                 Bye,
                 Gor Gyolchanyan.


             Replacing my custom new operator exactly by what?
             Overloading the build
             in new is deprecated...


         class C{
               class D{

               }
         }
         void main(){
               auto c = new C;
               auto buf = new void[__traits(__**classInstanceSize, C.D)];

               (cast(byte[])buf)[] = typeid(C.D).init[];
               auto d = cast(C.D)buf.ptr;
               static if(is(typeof(d.__ctor()))) d.__ctor();
               enum offset=d.outer.offsetof;
               static assert(offset%C.sizeof==0);
               (cast(C[])buf)[offset/C.__**sizeof]=c;

               assert(d.outer is c);
         }


     Yes of course I can assign the reference by computing the address
     and then using that to assign it. But the point here is, that this
     is currently the only bug that is hepling me in what I'm doing, and
     I rather want the 7 other bugs I reported so far to be fixed, rather
     then the one that helps me.

     Kind Regards
     Benjamin Thaut


 Not being able to assign is not about some sort of authoritative
 forbidding. It's about not breaking a working mechanism. You can't cast
 a function pointer into a class object not because the type system says
 so (which it does), but because that'll result in an undefined behavior,
 which will result in an immediate crash in the best scenario. Go ahead
 and change the outer via those hacks. But then don't get surprised when
 your program crashes for no reason (because the compiler assumed it not
 to change and ended up being wrong).

 --
 Bye,
 Gor Gyolchanyan.


 Before your change suggestion it was absolutley save to assign to outer.
 Thats the whole point why I posted this here. I very well know that the bug
 will get fixed some time. But before your change suggestion it was not even
 a bug.

 Kind Regards
 Benjamin Thaut


A bug remains a bug whether it was discovered or not. If it wasn't - it
would never get discovered. Even if the bug didn't get discovered for a
long time, making designs around bugs is a very bad idea precisely for this
reason. But it's not entirely your fault, because there's no reliable
reference to D at the moment, so it's very hard to determine what is and is
not supposed to work. That's one of the problems, that drive new commers
away: lack of a reference material.

-- 
Bye,
Gor Gyolchanyan.



 Jul 15 2012



prev sibling  parent reply Guillaume Chatelet <chatelet.guillaume gmail.com>  writes:


On 07/13/12 21:41, Andrei Alexandrescu wrote:

 On 7/13/12 3:36 PM, Gor Gyolchanyan wrote:

 The initial question was: why does DMD 2.059 reject this if this makes
 sense?
 It's not even a new feature. It's a (possibly) new (and apparently
 sensible) use case of an existing feature.


 
 I think the simple answer is there was no provision for it. The feature
 copies the Java feature, and I don't think Java has something like what
 you defined.
 
 Andrei
 


class Fruit {
    class Seed {
    }
}

class Apple extends Fruit {
    class AppleSeed extends Fruit.Seed {
        Apple getOuter() {
            return Apple.this;
        }
    }
}

class Main {
    public static void main(String[] args) {
        final Apple apple = new Apple();
        final Apple.AppleSeed appleSeed = apple.new AppleSeed();
        assert (appleSeed instanceof Fruit.Seed);
        assert (apple == appleSeed.getOuter());
        assert (appleSeed.getOuter() instanceof Apple);
        assert (appleSeed.getOuter() instanceof Fruit);
    }
}

This is valid Java code actually and I agree with Gor I would have
expected it to work with D.

Guillaume



 Jul 14 2012



 next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sat, Jul 14, 2012 at 1:36 PM, Guillaume Chatelet <
chatelet.guillaume gmail.com> wrote:


 On 07/13/12 21:41, Andrei Alexandrescu wrote:

 On 7/13/12 3:36 PM, Gor Gyolchanyan wrote:

 The initial question was: why does DMD 2.059 reject this if this makes
 sense?
 It's not even a new feature. It's a (possibly) new (and apparently
 sensible) use case of an existing feature.


 I think the simple answer is there was no provision for it. The feature
 copies the Java feature, and I don't think Java has something like what
 you defined.

 Andrei


 class Fruit {
     class Seed {
     }
 }

 class Apple extends Fruit {
     class AppleSeed extends Fruit.Seed {
         Apple getOuter() {
             return Apple.this;
         }
     }
 }

 class Main {
     public static void main(String[] args) {
         final Apple apple = new Apple();
         final Apple.AppleSeed appleSeed = apple.new AppleSeed();
         assert (appleSeed instanceof Fruit.Seed);
         assert (apple == appleSeed.getOuter());
         assert (appleSeed.getOuter() instanceof Apple);
         assert (appleSeed.getOuter() instanceof Fruit);
     }
 }

 This is valid Java code actually and I agree with Gor I would have
 expected it to work with D.

 Guillaume


I didn't even know this worked in Java. This means, that nested classed in
D can't translate nested classed in Java after all.

-- 
Bye,
Gor Gyolchanyan.



 Jul 14 2012



  parent  Paulo Pinto <pjmlp progtools.org>  writes:


Am 14.07.2012 11:45, schrieb Gor Gyolchanyan:

 On Sat, Jul 14, 2012 at 1:36 PM, Guillaume Chatelet
 <chatelet.guillaume gmail.com <mailto:chatelet.guillaume gmail.com>> wrote:

     On 07/13/12 21:41, Andrei Alexandrescu wrote:
      > On 7/13/12 3:36 PM, Gor Gyolchanyan wrote:
      >> The initial question was: why does DMD 2.059 reject this if this
     makes
      >> sense?
      >> It's not even a new feature. It's a (possibly) new (and apparently
      >> sensible) use case of an existing feature.
      >
      > I think the simple answer is there was no provision for it. The
     feature
      > copies the Java feature, and I don't think Java has something
     like what
      > you defined.
      >
      > Andrei
      >

     class Fruit {
          class Seed {
          }
     }

     class Apple extends Fruit {
          class AppleSeed extends Fruit.Seed {
              Apple getOuter() {
                  return Apple.this;
              }
          }
     }

     class Main {
          public static void main(String[] args) {
              final Apple apple = new Apple();
              final Apple.AppleSeed appleSeed = apple.new AppleSeed();
              assert (appleSeed instanceof Fruit.Seed);
              assert (apple == appleSeed.getOuter());
              assert (appleSeed.getOuter() instanceof Apple);
              assert (appleSeed.getOuter() instanceof Fruit);
          }
     }

     This is valid Java code actually and I agree with Gor I would have
     expected it to work with D.

     Guillaume


 I didn't even know this worked in Java. This means, that nested classed
 in D can't translate nested classed in Java after all.


This usually comes up in certification and interview questions.



 Jul 14 2012



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/14/12 5:36 AM, Guillaume Chatelet wrote:

 class Fruit {
      class Seed {
      }
 }

 class Apple extends Fruit {
      class AppleSeed extends Fruit.Seed {
          Apple getOuter() {
              return Apple.this;
          }
      }
 }

 class Main {
      public static void main(String[] args) {
          final Apple apple = new Apple();
          final Apple.AppleSeed appleSeed = apple.new AppleSeed();
          assert (appleSeed instanceof Fruit.Seed);
          assert (apple == appleSeed.getOuter());
          assert (appleSeed.getOuter() instanceof Apple);
          assert (appleSeed.getOuter() instanceof Fruit);
      }
 }

 This is valid Java code actually and I agree with Gor I would have
 expected it to work with D.

 Guillaume


You may want to add the example to the bug report.

Thanks,

Andrei



 Jul 14 2012



  parent  Guillaume Chatelet <chatelet.guillaume gmail.com>  writes:


On 07/14/12 13:51, Andrei Alexandrescu wrote:

 On 7/14/12 5:36 AM, Guillaume Chatelet wrote:

 class Fruit {
      class Seed {
      }
 }

 class Apple extends Fruit {
      class AppleSeed extends Fruit.Seed {
          Apple getOuter() {
              return Apple.this;
          }
      }
 }

 class Main {
      public static void main(String[] args) {
          final Apple apple = new Apple();
          final Apple.AppleSeed appleSeed = apple.new AppleSeed();
          assert (appleSeed instanceof Fruit.Seed);
          assert (apple == appleSeed.getOuter());
          assert (appleSeed.getOuter() instanceof Apple);
          assert (appleSeed.getOuter() instanceof Fruit);
      }
 }

 This is valid Java code actually and I agree with Gor I would have
 expected it to work with D.

 Guillaume


 
 You may want to add the example to the bug report.
 
 Thanks,
 
 Andrei


Done.
http://d.puremagic.com/issues/show_bug.cgi?id=8389

Guillaume



 Jul 14 2012



prev sibling next sibling parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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.



 Jul 13 2012



prev sibling  parent  deadalnix <deadalnix gmail.com>  writes:


On 13/07/2012 21:10, Andrei Alexandrescu 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>>
 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


An Apple is a Fruit, so it shouldn't be a problem and don't require 2 
fields.



 Jul 14 2012



prev sibling next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com>  writes:


On Friday, 13 July 2012 at 18:00:05 UTC, Gor Gyolchanyan wrote:

 Doesn't this make sense?

 class Fruit
 {
     class Seed { }
 }

 class Apple: Fruit
 {
      class AppleSeed: Fruit.Seed { }
 }

 This means, that as Fruit.Seed needs access to enclosing Fruit, 
 AppleSeed, being a Fruit.Seed will also have access to 
 enclosing Fruit, which is Apple.
 DMD 0.259 has this to say:

 Error: class main.Apple.AppleSeed is nested within Apple, but  
 super class Seed is nested within Fruit

 Which doesn't make sense, IMO. What do you guys think about 
 this? Who makes more sense me or DMD 2.059?


  I'd say DMD makes more sense. Seed has knowledge of itself AND 
Fruit. So if it's following the same rules and for how it makes 
sense, then unless you add static to Seed, then you won't get it 
to work. Reminds me of when I used Java years ago experimenting 
with inner classes, came to a distinct conclusion of object 
referencing and why it didn't want to work without an outer 
object.

  Consider: fails on seed, not seed2.

class Fruit {
  int x;
  class Seed {
   void oneMoreToX() {
    x++; //knows about Fruit.x, even if not instantiated
   }
  }

  static class Seed2 {
   void oneMoreToX() {
//  x++; //fails to compile, no knowledge of Fruit
   }
  }
}

class Apple: Fruit {
  class AppleSeed: Fruit.Seed { } //fails (no outer object 
(Fruit.x) and makes no sense)
  class AppleSeed2: Fruit.Seed2 { } //works fine
}



 Jul 13 2012



 next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Fri, Jul 13, 2012 at 10:25 PM, Era Scarecrow <rtcvb32 yahoo.com> wrote:


 On Friday, 13 July 2012 at 18:00:05 UTC, Gor Gyolchanyan wrote:


 Doesn't this make sense?

 class Fruit
 {
     class Seed { }
 }

 class Apple: Fruit
 {
      class AppleSeed: Fruit.Seed { }
 }

 This means, that as Fruit.Seed needs access to enclosing Fruit,
 AppleSeed, being a Fruit.Seed will also have access to enclosing Fruit,
 which is Apple.
 DMD 0.259 has this to say:

 Error: class main.Apple.AppleSeed is nested within Apple, but  super
 class Seed is nested within Fruit

 Which doesn't make sense, IMO. What do you guys think about this? Who
 makes more sense me or DMD 2.059?


  I'd say DMD makes more sense. Seed has knowledge of itself AND Fruit. So
 if it's following the same rules and for how it makes sense, then unless
 you add static to Seed, then you won't get it to work. Reminds me of when I
 used Java years ago experimenting with inner classes, came to a distinct
 conclusion of object referencing and why it didn't want to work without an
 outer object.

  Consider: fails on seed, not seed2.

 class Fruit {
  int x;
  class Seed {
   void oneMoreToX() {
    x++; //knows about Fruit.x, even if not instantiated
   }
  }

  static class Seed2 {
   void oneMoreToX() {
 //  x++; //fails to compile, no knowledge of Fruit
   }
  }
 }

 class Apple: Fruit {
  class AppleSeed: Fruit.Seed { } //fails (no outer object (Fruit.x) and
 makes no sense)
  class AppleSeed2: Fruit.Seed2 { } //works fine
 }


I need Seed to have a reference to Fruit because there will be more then
one derivative of Seed in the same derivative of Fruit and they all need to
store data inside the fruit and communicate with each other in that way.
That's why Seed can't be static. What can I do to have multiple seeds in
the same fruit with all seed-fruit-seed communication hidden in the base
classes?

-- 
Bye,
Gor Gyolchanyan.



 Jul 13 2012



  parent reply "Era Scarecrow" <rtcvb32 yahoo.com>  writes:


On Friday, 13 July 2012 at 18:34:06 UTC, Gor Gyolchanyan wrote:

 I need Seed to have a reference to Fruit because there will be 
 more then one derivative of Seed in the same derivative of 
 Fruit and they all need to store data inside the fruit and 
 communicate with each other in that way. That's why Seed can't 
 be static. What can I do to have multiple seeds in the same 
 fruit with all seed-fruit-seed communication hidden in the base 
 classes?



  Then perhaps have the inherited class within fruit?

class Fruit {
   class Seed {}
   class Appleseed : Seed {}
}



 Jul 13 2012



  parent reply travert phare.normalesup.org (Christophe Travert)  writes:


"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....



 Jul 13 2012



 next sibling parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Fri, Jul 13, 2012 at 10:55 PM, Christophe Travert <
travert phare.normalesup.org> wrote:


 "Era Scarecrow" , dans le message (digitalmars.D:172272), a =C3=A9crit :

   Then perhaps have the inherited class within fruit?

 class Fruit {
    class Seed {}
    class Appleseed : Seed {}
 }


 But then AppleSeed doesn't know about Apple....


Right. And Fruit.Seed can't know about Apple either, because there are tons
of fruits like Apple, each of which can have tons of different Seeds.
I really didn't get why my original example didn't make sense.

--=20
Bye,
Gor Gyolchanyan.



 Jul 13 2012



prev sibling  parent reply "Era Scarecrow" <rtcvb32 yahoo.com>  writes:


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.



 Jul 13 2012



  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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(Chr=


istophe Travert) wrote:

 "Era Scarecrow" , dans le message (digitalmars.D:172272), a =C3=A9crit :


   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 Frui=


t

 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 n=


ot

 that many levels.


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

--=20
Bye,
Gor Gyolchanyan.



 Jul 13 2012



  parent reply "Era Scarecrow" <rtcvb32 yahoo.com>  writes:


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.



 Jul 13 2012



  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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.



 Jul 13 2012



  parent reply "Era Scarecrow" <rtcvb32 yahoo.com>  writes:


On Friday, 13 July 2012 at 19:35:34 UTC, Gor Gyolchanyan wrote:

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


  The interface itself may not have state, but what uses the 
interface can have state. So i don't see an issue. Worse case you 
can use an abstract class which is a partial definition.

interface Counter {
   void addOne();
   int getCount();
}

//A contains state and is both A and Counter.
class A : Counter {
   int x;
   void addOne() {x++;}
   void getCount() {return x;}
}


 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 far...
class Fruit {
  class Seed {
   class Apple {}
  }
}


 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.


Hmmm...
interface Seed {}

class Fruit {
   class Appleseed : Seed {
     class Apple {}
   }

   //or?
   static class Apple {
     class AppleSeed : Seed {} //multiple seeds, but need Fruit 
access?
   }
}

or perhaps...?

interface Seed{}
interface Fruit{}

//Apple knows it's a fruit..
class Apple : Fruit {
   //Appleseed is from the Apple (which is a fruit as well)
   //Appleseed is a seed, we can have multiple seeds from Apple, 
all which know
   //all about Apple's (and basic fruits) but not about non-appple 
seeds.
   class Appleseed : Seed {
   }
}



 Jul 13 2012



  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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


 On Friday, 13 July 2012 at 19:35:34 UTC, Gor Gyolchanyan wrote:


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


  The interface itself may not have state, but what uses the interface can
 have state. So i don't see an issue. Worse case you can use an abstract
 class which is a partial definition.

 interface Counter {
   void addOne();
   int getCount();
 }

 //A contains state and is both A and Counter.
 class A : Counter {
   int x;
   void addOne() {x++;}
   void getCount() {return x;}

 }

  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 far...

 class Fruit {
  class Seed {
   class Apple {}
  }
 }



 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.


 Hmmm...
 interface Seed {}

 class Fruit {
   class Appleseed : Seed {
     class Apple {}
   }

   //or?
   static class Apple {
     class AppleSeed : Seed {} //multiple seeds, but need Fruit access?
   }
 }

 or perhaps...?

 interface Seed{}
 interface Fruit{}

 //Apple knows it's a fruit..
 class Apple : Fruit {
   //Appleseed is from the Apple (which is a fruit as well)
   //Appleseed is a seed, we can have multiple seeds from Apple, all which
 know
   //all about Apple's (and basic fruits) but not about non-appple seeds.
   class Appleseed : Seed {
   }
 }


The seed itself must have private state, or else it would violate
encapsulation and require nasty mixins.
And as I said, fruit can't know about apple.

-- 
Bye,
Gor Gyolchanyan.



 Jul 13 2012



  parent  "Era Scarecrow" <rtcvb32 yahoo.com>  writes:


On Friday, 13 July 2012 at 20:04:43 UTC, Gor Gyolchanyan wrote:

 On Fri, Jul 13, 2012 at 11:59 PM, Era Scarecrow

 or perhaps...?

 interface Seed{}
 interface Fruit{}

 //Apple knows it's a fruit..
 class Apple : Fruit {
   //Appleseed is from the Apple (which is a fruit as well)
   //Appleseed is a seed, we can have multiple seeds from 
 Apple, all which
 know
   //all about Apple's (and basic fruits) but not about 
 non-appple seeds.
   class Appleseed : Seed {
   }
 }


 The seed itself must have private state, or else it would 
 violate encapsulation and require nasty mixins.
 And as I said, fruit can't know about apple.


  Fruit doesn't know about apples in this last case, only that an 
apple IS a fruit (And can do anything a fruit can do). And the 
seed CAN have a private state, only part of the interface (from 
interface Seed) is exposed. So I do not see a problem.

  interface Seed {
    void func();
  }

  class Appleseed : Seed {
   int x; //private state
   void func() {x++;}
  }

  Appleseed a = new Appleseed();
  Seed s = cast(Seed) a;

  //appleseed
  a.func();
  a.x = 5;

  //seed
  s.func(); //known and callable
  s.x = 10; //error, x isn't defined or known in seed. How is this 
not private state?



 Jul 13 2012



prev sibling  parent  travert phare.normalesup.org (Christophe Travert)  writes:


"Era Scarecrow" , dans le message (digitalmars.D:172269), a écrit :

 class Fruit {
   int x;
   class Seed {
    void oneMoreToX() {
     x++; //knows about Fruit.x, even if not instantiated
    }
   }
 
   static class Seed2 {
    void oneMoreToX() {
 //  x++; //fails to compile, no knowledge of Fruit
    }
   }
 }
 
 class Apple: Fruit {
   class AppleSeed: Fruit.Seed { } //fails (no outer object 
 (Fruit.x) and makes no sense)
   class AppleSeed2: Fruit.Seed2 { } //works fine
 }


AppleSeed does have a outer Fruit, and this Fruit happens to be an 
Apple. I don't see what is the issue, and what prevents the langage to 
support such AppleSeed. I'm not saying there is nothing that prevents 
the langage to support such pattern, I am not used to inner classes. 
Pleas enlighten me.



 Jul 13 2012



prev sibling next sibling parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Fri, 13 Jul 2012 13:59:54 -0400, Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com> wrote:


 Doesn't this make sense?

 class Fruit
 {
     class Seed { }
 }

 class Apple: Fruit
 {
      class AppleSeed: Fruit.Seed { }
 }

 This means, that as Fruit.Seed needs access to enclosing Fruit,  
 AppleSeed,
 being a Fruit.Seed will also have access to enclosing Fruit, which is  
 Apple.
 DMD 0.259 has this to say:

 Error: class main.Apple.AppleSeed is nested within Apple, but super class
 Seed is nested within Fruit

 Which doesn't make sense, IMO. What do you guys think about this? Who  
 makes
 more sense me or DMD 2.059?



This is what you are asking for:

class A {}

class B : A {}

class C
{
    A member;
}

class D : C
{
    override B member;
}

You can mimic it via:

class C
{
    protected A _member;
     property inout(A) member() inout { return _member; }
}

class C : B
{
    override  property inout(B) member() inout { return  
cast(inout(B))_member; }
}

I have had many times where I had to do this workaround (with casting), or  
store extra references, but it would be nice to have this simply work  
depending on the type.  I don't think anyone considered doing this with  
outer, it certainly would be a valid feature.  I'd like to have the  
general feature as well.  Covariant fields...

-Steve



 Jul 13 2012



prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Friday, 13 July 2012 at 18:00:05 UTC, Gor Gyolchanyan wrote:

 Which doesn't make sense, IMO. What do you guys think about 
 this? Who makes
 more sense me or DMD 2.059?


http://d.puremagic.com/issues/show_bug.cgi?id=1175
https://github.com/D-Programming-Language/dmd/pull/889



 Jul 14 2012



 next sibling parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sat, Jul 14, 2012 at 1:41 PM, Vladimir Panteleev <
vladimir thecybershadow.net> wrote:


 On Friday, 13 July 2012 at 18:00:05 UTC, Gor Gyolchanyan wrote:


 Which doesn't make sense, IMO. What do you guys think about this? Who
 makes
 more sense me or DMD 2.059?


 http://d.puremagic.com/issues/**show_bug.cgi?id=1175<http://d.puremagic.com/issues/show_bug.cgi?id=1175>
 https://github.com/D-**Programming-Language/dmd/pull/**889<https://github.com/D-Programming-Language/dmd/pull/889>


I see it's already merged. I presume this will end up in DMD 2.060, right?

-- 
Bye,
Gor Gyolchanyan.



 Jul 14 2012



prev sibling next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday, July 14, 2012 13:47:29 Gor Gyolchanyan wrote:

 I see it's already merged. I presume this will end up in DMD 2.060, right?


Anything and everything which has already been merged on github will end up in 
the next release of dmd unless it's reverted or altered by another commit 
prior to the next release. We don't currently maintain any branches as part of 
the development process.

- Jonathan M Davis



 Jul 14 2012



prev sibling next sibling parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sat, Jul 14, 2012 at 1:56 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


 On Saturday, July 14, 2012 13:47:29 Gor Gyolchanyan wrote:

 I see it's already merged. I presume this will end up in DMD 2.060,


 right?

 Anything and everything which has already been merged on github will end
 up in
 the next release of dmd unless it's reverted or altered by another commit
 prior to the next release. We don't currently maintain any branches as
 part of
 the development process.

 - Jonathan M Davis


That's great. That means, I don't have to work around it and I can just
wait a bit until DMD 2.060 comes out. Btw, when will it happen?

-- 
Bye,
Gor Gyolchanyan.



 Jul 14 2012



prev sibling  parent reply Guillaume Chatelet <chatelet.guillaume gmail.com>  writes:


On 07/14/12 11:41, Vladimir Panteleev wrote:

 On Friday, 13 July 2012 at 18:00:05 UTC, Gor Gyolchanyan wrote:

 Which doesn't make sense, IMO. What do you guys think about this? Who
 makes
 more sense me or DMD 2.059?


 
 http://d.puremagic.com/issues/show_bug.cgi?id=1175
 https://github.com/D-Programming-Language/dmd/pull/889
 


So I marked 8389 as a duplicate of 1175 and closed the issue ( as 1175
has been resolved too)
I hope you don't mind Gor. Feel free to reopen if needed.

Guillaume



 Jul 14 2012



  parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sat, Jul 14, 2012 at 4:17 PM, Guillaume Chatelet <
chatelet.guillaume gmail.com> wrote:


 On 07/14/12 11:41, Vladimir Panteleev wrote:

 On Friday, 13 July 2012 at 18:00:05 UTC, Gor Gyolchanyan wrote:

 Which doesn't make sense, IMO. What do you guys think about this? Who
 makes
 more sense me or DMD 2.059?


 http://d.puremagic.com/issues/show_bug.cgi?id=1175
 https://github.com/D-Programming-Language/dmd/pull/889


 So I marked 8389 as a duplicate of 1175 and closed the issue ( as 1175
 has been resolved too)
 I hope you don't mind Gor. Feel free to reopen if needed.

 Guillaume


Sure, it's fine. :-) As long as the damn thing works. :-D

-- 
Bye,
Gor Gyolchanyan.



 Jul 14 2012



prev sibling next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday, July 14, 2012 14:00:14 Gor Gyolchanyan wrote:

 That's great. That means, I don't have to work around it and I can just
 wait a bit until DMD 2.060 comes out. Btw, when will it happen?


No idea. Normally, releases have been happening every 2 months or so, but 
we're at just passed 3 months since the last one now. It pretty much depends 
on when Walter decides to do a beta. He made noise about that over a month ago 
but didn't end up doing it (I think that he went on vacation shortly after 
that), and he hasn't said anything about it since. We should probably do one 
soon though.

- Jonathan M Davis



 Jul 14 2012



prev sibling next sibling parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sat, Jul 14, 2012 at 2:04 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


 On Saturday, July 14, 2012 14:00:14 Gor Gyolchanyan wrote:

 That's great. That means, I don't have to work around it and I can just
 wait a bit until DMD 2.060 comes out. Btw, when will it happen?


 No idea. Normally, releases have been happening every 2 months or so, but
 we're at just passed 3 months since the last one now. It pretty much
 depends
 on when Walter decides to do a beta. He made noise about that over a month
 ago
 but didn't end up doing it (I think that he went on vacation shortly after
 that), and he hasn't said anything about it since. We should probably do
 one
 soon though.

 - Jonathan M Davis


I see. Is it possible to get the change log for the upcoming release? That
would also show us what we shouldn't work around.

-- 
Bye,
Gor Gyolchanyan.



 Jul 14 2012



prev sibling next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday, July 14, 2012 14:21:01 Gor Gyolchanyan wrote:

 On Sat, Jul 14, 2012 at 2:04 PM, Jonathan M Davis 


<jmdavisProg gmx.com>wrote:

 On Saturday, July 14, 2012 14:00:14 Gor Gyolchanyan wrote:

 That's great. That means, I don't have to work around it and I can just
 wait a bit until DMD 2.060 comes out. Btw, when will it happen?


 
 No idea. Normally, releases have been happening every 2 months or so, but
 we're at just passed 3 months since the last one now. It pretty much
 depends
 on when Walter decides to do a beta. He made noise about that over a month
 ago
 but didn't end up doing it (I think that he went on vacation shortly after
 that), and he hasn't said anything about it since. We should probably do
 one
 soon though.
 
 - Jonathan M Davis


 
 I see. Is it possible to get the change log for the upcoming release? That
 would also show us what we shouldn't work around.


Yes and no. If you look in each repository, there's a partial changelog for 
each (changelog.dd), but odds are that they're missing a number of items, and 
actually, for some reason, dmd's hasn't been updated in a year, so I have no 
clue how Walter puts together dmd's portion of the changelog.

Andrei recently brought up the idea of automatically generating the bug fix 
list for the changelog with a query to bugzilla, which would make sure that 
everything made it into the changelog (right now, it depends on the devs 
making sure that they manually add it all, and stuff gets missed). I believe 
that this query will list every bug that has been fixed since 2.059:

http://d.puremagic.com/issues/buglist.cgi?bug_status=RESOLVED&chfieldto=Now&chfield=bug_status&query_format=advanced&chfieldfrom=2012-04-12&resolution=FIXED

which as you can see is far from being short.

- Jonathan M Davis



 Jul 14 2012



prev sibling  parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


On Sat, Jul 14, 2012 at 2:35 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


 On Saturday, July 14, 2012 14:21:01 Gor Gyolchanyan wrote:

 On Sat, Jul 14, 2012 at 2:04 PM, Jonathan M Davis


 <jmdavisProg gmx.com>wrote:

 On Saturday, July 14, 2012 14:00:14 Gor Gyolchanyan wrote:

 That's great. That means, I don't have to work around it and I can






 just

 wait a bit until DMD 2.060 comes out. Btw, when will it happen?


 No idea. Normally, releases have been happening every 2 months or so,




 but

 we're at just passed 3 months since the last one now. It pretty much
 depends
 on when Walter decides to do a beta. He made noise about that over a




 month

 ago
 but didn't end up doing it (I think that he went on vacation shortly




 after

 that), and he hasn't said anything about it since. We should probably




 do

 one
 soon though.

 - Jonathan M Davis


 I see. Is it possible to get the change log for the upcoming release?


 That

 would also show us what we shouldn't work around.


 Yes and no. If you look in each repository, there's a partial changelog for
 each (changelog.dd), but odds are that they're missing a number of items,
 and
 actually, for some reason, dmd's hasn't been updated in a year, so I have
 no
 clue how Walter puts together dmd's portion of the changelog.

 Andrei recently brought up the idea of automatically generating the bug fix
 list for the changelog with a query to bugzilla, which would make sure that
 everything made it into the changelog (right now, it depends on the devs
 making sure that they manually add it all, and stuff gets missed). I
 believe
 that this query will list every bug that has been fixed since 2.059:


 http://d.puremagic.com/issues/buglist.cgi?bug_status=RESOLVED&chfieldto=Now&chfield=bug_status&query_format=advanced&chfieldfrom=2012-04-12&resolution=FIXED

 which as you can see is far from being short.

 - Jonathan M Davis


Auto-generating a change log is a great idea. I think it would be great to
generate the change log for all previous versions as well and diff it with
the existing change log to see the changes that didn't show up in the
change log.

-- 
Bye,
Gor Gyolchanyan.



 Jul 14 2012