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