www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - how to change attribute in descendant?

reply novice2 <sorry noem.ail> writes:
Hello.
I need declare some base class A with general functionality, then
more special descendants AA and AB.
"A" class have some fields, that i don't want "show", i make it
protected. Then in some descendant i need "open" it. I need change
it from "protected" to "public".
In Delphi i just redeclare it in descendant, but in "public"
section. Delphi allow change visibility of class members from low
to higher. Private->protected->public.

How i can do this in D?

/********* test.d ********/

import std.stdio;

//base class with general code

abstract class Animal
{
  protected int legsCount;

  protected int poisonStrength;

  public bool canWalk()
  {
    return legsCount>0;
  }

  public bool canKill()
  {
    return poisonStrength>0;
  }
}


//tiger = animal with legs without poison

class Tiger : Animal
{
  public int legsCount;
}


//snake = animal without legs with poison

class Snake : Animal
{
  public int poisonStrength;
}


void main()
{
  Tiger t = new Tiger;
  t.legsCount = 4;
  writefln("tiger: legs=%d, canWalk=%d, canKill=%d", t.legsCount,
t.canWalk, t.canKill);

  Snake s = new Snake;
  s.poisonStrength = 100;
  writefln("snake: poison=%d, canWalk=%d, canKill=%d",
s.poisonStrength, s.canWalk, s.canKill);
}

output:
tiger: legs=4, canWalk=0, canKill=0
snake: poison=100, canWalk=0, canKill=0
Jan 18 2007
next sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
novice2 wrote:
 Hello.
 I need declare some base class A with general functionality, then
 more special descendants AA and AB.
 "A" class have some fields, that i don't want "show", i make it
 protected. Then in some descendant i need "open" it. I need change
 it from "protected" to "public".
 In Delphi i just redeclare it in descendant, but in "public"
 section. Delphi allow change visibility of class members from low
 to higher. Private->protected->public.

It's funny you post this now. I had a co-worker who had the same exact same problem in Java yesterday. :) In short: fields cannot be overridden in the same way that methods can. Even though the compiler lets you do this: class A{ char[] name = "Class A"; } class B:A{ char[] name = "Class B"; } ... it is considered bad form. Avoid doing this if you can. A matching member name, instead of overriding the declaration within the super-class, subtly *masks* the super-class' declaration instead. Technically, both fields co-exist, side-by-side. This is because the compiler treats all member declarations the same, regardless if they match a super-class' member name (regardless of type). Obviously, this can become very confusing: void main(){ A a = new A(); B b = new B(); writefln("A: %s",a.name); // prints: Class A writefln("B: %s",b.name); // prints: Class B writefln("B: %s",(cast(A)b).name); // prints: Class A <-- A.name is still there, and is not overridden } The way to fix this is pretty straightforward. Just use one field only for any such purpose: class A{ char[] name; this(){ name = "Class A"; } } class B:A{ this(){ name = "Class B"; } } This way, every 'A' and every subclass of 'A' will have the same 'name' field. It then down to each subclass to change the value of 'name' as is appropriate. In the case of your program, where you try to 'open' things up as you go down the hierarchy, you can do something like this: class A{ private char[] myName; protected char[] name(){ return myName; } this(){ myName= "Class A"; } } class B:A{ public char[] name(){ return myName; } this(){ myName= "Class B"; } } Again, since only methods can be overridden, this is the only way to go. This example also demonstrates D's property syntax, which is a nice concession for situations like this. Try using this snippet with the "void main()" snippet above. :) -- - EricAnderton at yahoo
Jan 18 2007
next sibling parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
Pragma wrote:
 This example also demonstrates D's property syntax, which is a nice
 concession for situations like this.  Try using this snippet with the
 "void main()" snippet above. :)

Eric, do you happen to know, if it's possible to do the opposite - i.e. make public methods private by using private/protected inheritance? The spec says (http://www.digitalmars.com/d/class.html): InterfaceClass: Identifier Protection Identifier Protection: private package public export But what does it mean? I've asked this a few times before (nobody answered). The compiler just bypasses the protection attributes. I think other than public inheritance is anyway bad in D, especially when the protection is used with interfaces.
Jan 18 2007
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Jari-Matti Mäkelä wrote:
 Pragma wrote:
 This example also demonstrates D's property syntax, which is a nice
 concession for situations like this.  Try using this snippet with the
 "void main()" snippet above. :)

Eric, do you happen to know, if it's possible to do the opposite - i.e. make public methods private by using private/protected inheritance? The spec says (http://www.digitalmars.com/d/class.html): InterfaceClass: Identifier Protection Identifier Protection: private package public export But what does it mean? I've asked this a few times before (nobody answered). The compiler just bypasses the protection attributes. I think other than public inheritance is anyway bad in D, especially when the protection is used with interfaces.

(I'm assuming that you're coming from a novice background here - my apologies if this is not the case) Sadly the documentation is kind of in an "expert mode" state at the moment. In many places, it assumes that you're already familiar with C++ or Java - most of us here are, so we mentally fill in these gaps without realizing they're missing! *ahem* anyway, the protection attributes break down like so: public - accessible by all protected - accessible by the declaring scope and any scopes that inherit it private - only accessible by the declaring scope package - accessible by all, *within the same package* export - accessible by external programs and libraries (it's of out of place in this discussion) ...where a scope is a module, interface, class or struct. Well one thing that isn't illustrated in the grammar (quoted above) is that 'public' is implied for anything accessed from within the same module - perhaps this is what you're seeing when the compiler 'bypasses' things? You have to break your classes and interfaces out into distinct files for these attributes to be enforced as you'd expect. While I know this seems odd, it's much better than what Java or C++ would have to do to achieve the same effect. From the perspective of someone (me) who writes libraries in D, it's a help and not a hindrance. -- - EricAnderton at yahoo
Jan 18 2007
parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
Pragma kirjoitti:
 Jari-Matti Mäkelä wrote:
 Eric, do you happen to know, if it's possible to do the opposite - i.e.
 make public methods private by using private/protected inheritance? The
 spec says (http://www.digitalmars.com/d/class.html):

 InterfaceClass:
         Identifier
         Protection Identifier

 Protection:
         private
         package
         public
         export

 But what does it mean? I've asked this a few times before (nobody
 answered). The compiler just bypasses the protection attributes. I think
 other than public inheritance is anyway bad in D, especially when the
 protection is used with interfaces.

(I'm assuming that you're coming from a novice background here - my apologies if this is not the case)

Sorry - the question was a bit naive. What I meant was that why isn't it working.
 
 ...where a scope is a module, interface, class or struct.
 
 Well one thing that isn't illustrated in the grammar (quoted above) is
 that 'public' is implied for anything accessed from within the same
 module

Yes.
- perhaps this is what you're seeing when the compiler 'bypasses'
 things?

No. You see, if I read and quess the grammar correctly, some of this should work: module aaa; interface A { public void a(); // the public is of course implied here } class B { public void b() { } } --- module bbb class C : private A, private B // the problem is this part of the grammar { private void a() { } } --- module ccc void main() { auto a = new C(); a.a(); // should raise a compile time error ? a.b(); // should raise a compile time error } --- Here's the same code in standard C++ and it correctly raises a compile time error: #include <stdio.h> class A { public: void a() { printf("hello"); } }; class B: private A { }; int main() { B *b = new B(); b->a(); return 0; }
 You have to break your classes and interfaces out into distinct
 files for these attributes to be enforced as you'd expect.

But it doesn't help.
Jan 18 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jari-Matti Mkel" <jmjmak utu.fi.invalid> wrote in message 
news:eooa7j$1bie$1 digitaldaemon.com...

 Sorry - the question was a bit naive. What I meant was that why isn't it
 working.

Since the spec never says anything about protection on base classes/interfaces, and since it's been asked about many times, I guess it's one of two things: (1) a vestige from a long, long time ago when these were planned to work, but were never implemented, or (2) just there for future expansion. It'd be interesting to see what code is there for it in the compiler frontend.
Jan 18 2007
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Jarrett Billingsley kirjoitti:
 "Jari-Matti Mkel" <jmjmak utu.fi.invalid> wrote in message 
 news:eooa7j$1bie$1 digitaldaemon.com...
 
 Sorry - the question was a bit naive. What I meant was that why isn't it
 working.

Since the spec never says anything about protection on base classes/interfaces, and since it's been asked about many times, I guess it's one of two things: (1) a vestige from a long, long time ago when these were planned to work, but were never implemented, or (2) just there for future expansion. It'd be interesting to see what code is there for it in the compiler frontend.

They have been a very long time there. I suppose Walter has copied them from the C++ spec and forgotten a bit later. I don't mind even if D won't support them, since Java also has plain public inheritance and it's still usable as a language. Most of the information hiding can be done by abstracting the classes more. Private inheritance at least might cause some odd corner cases on runtime when used in conjunction with the implicit friend syntax within the same module and interfaces.
Jan 18 2007
prev sibling parent novice <sorry noem.ail> writes:
== Quote from Pragma (ericanderton yahoo.removeme.com)'s article
 In short: fields cannot be overridden in the same way that

Thank you for explanation. Delphi ability knowing confuse me.
Jan 18 2007
prev sibling parent reply %u <u infearof.spm> writes:
novice2 Wrote:

 Then in some descendant i need "open" it.

Descendendants, as you say, need to be like ancestors without any restrictions. Thus there cannot be any need to "open" any closed "attributes". IMO you mean something like this: class Animal{ Attribute walk=null, kill=null; bool canWalk(){ return walk !is null;} bool canKill(){ return kill !is null;} } class Tiger:Animal{ this(){ walk= new Walk(4);} } class Walk:Attribute{ int legs; this( int count){ legs= count; }; } class Attribute{} void main(){ Tiger t= new Tiger; writefln( t.walk.legs, t.canWalk, t.canKill); ...
Jan 18 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"%u" <u infearof.spm> wrote in message 
news:eop4o3$2mq1$1 digitaldaemon.com...
 novice2 Wrote:

 Then in some descendant i need "open" it.

orientation. Descendendants, as you say, need to be like ancestors without any restrictions. Thus there cannot be any need to "open" any closed "attributes".

OT: Mr/s. %u, would you please, please use a newsreader? There is a bug in the web interface which messes up your name when you post, and it's really disconcerting not knowing your name (and indeed, whether or not all the posts by %u are by the same author).
Jan 18 2007