www.digitalmars.com         C & C++   DMDScript  

D - Method Blocking

reply Benji Smith <dlanguage xxagg.com> writes:
Here's an idea that I've been aching for in several different
languages: method blocking.

I often create base classes that will have lots of different kinds of
derived classes. To avoid duplicating code, I put all the method
definitions in the base class, so that they can be inherited by the
derived classes that really need them. But not all of the derived
classes should have access to all of the methods in the parent class,
and I'd like to block them.

Take a look at this code:

class baseClass {
	public void doSomething() {
		...
	}
	public void doSomethingElse() {
		...
	}
}
class derivedClassA: baseClass {
	public void doSomethingFun() {

	}
}
class derivedClassB: baseClass {
	block void doSomething();
	public void doSomethingSilly() {

	}
}

In this example, my base class has two methods: "doSomething()" and
"doSomethingElse()". The class derivedClassA inherits both of these
virtual functions, but the class derivedClassB specifically blocks the
use of the "doSomething()" function. Attempting to call this function
should result in a compiler error, not in a runtime exception.

In the past, I've used exceptions to define class hierarchies like
this. I'll define the methods that I need in the base class, and then
I'll overload those functions in the derived classes, something like
this:

class derivedClassB: baseClass {
	public void doSomething() {
	throw new Exception("Cannot call doSomething from a
		derivedClassB object");
	}
	public void doSomethingSilly() {

	}
}

But throwing exceptions is costly, and besides, I should be able to
know AT COMPILE TIME if I'm calling methods that shouldn't exist
anyhow.

I've been wishing for functionality like this for ages, and I can't
fathom why it isn't available. It seems like it would be easy to use
the "block" keyword to simply remove an entry from the v-table,
wouldn't it?
Aug 13 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
why make base::doSomthing public if you don't want it callable from a sub
class ??

by saying
class Base {
    public void func() {... }
}
you are defining the base "interface" of your object
(java has the "final" keyword to stop you redefining a functions in a super
class)
but if you realy do no want func to be called for a super class I would say
your object heirachy is wrong somewhere, or is should be

class Base {
    private void func() {... } // only callable by Base and only implemented
here
}

or protected if you want to allow the Derived classes to access them but not
others.

-----------------------------

import c.stdio;

class A {
 this() { printf("A::this()\n"); }
 protected void show() { printf("A::show()\n"); }
 protected void shout() { printf("A::shout()\n"); }
}

class B : A {
 this() { printf("B::this()\n"); }
 public void show() { super.show(); printf("B::show()\n"); }
}

class C : A {
 this() { printf("C::this()\n"); }
 public void shout() { super.shout(); printf("C::shout()\n"); }
}

int main( char[][] args ) {
 A b = new B();
 A c = new C();
 b.show();
 c.show();

/* // errr!!! was going to be
 B b = new B();
 C c = new C();
 b.show();
 c.shout();
*/
 return 0;
}
-----------------------------------------
for some reason this works!! but a::show is protected so should only be
accesable from sub class ??

sounds to me like you are trying to write code without thinking about the oo
design of you classes.

"Benji Smith" <dlanguage xxagg.com> wrote in message
news:h2ikjv8f8bf6h09fnamt6ivuehqb5401vv 4ax.com...
 Here's an idea that I've been aching for in several different
 languages: method blocking.

 I often create base classes that will have lots of different kinds of
 derived classes. To avoid duplicating code, I put all the method
 definitions in the base class, so that they can be inherited by the
 derived classes that really need them. But not all of the derived
 classes should have access to all of the methods in the parent class,
 and I'd like to block them.

 Take a look at this code:

 class baseClass {
 public void doSomething() {
 ...
 }
 public void doSomethingElse() {
 ...
 }
 }
 class derivedClassA: baseClass {
 public void doSomethingFun() {

 }
 }
 class derivedClassB: baseClass {
 block void doSomething();
 public void doSomethingSilly() {

 }
 }

 In this example, my base class has two methods: "doSomething()" and
 "doSomethingElse()". The class derivedClassA inherits both of these
 virtual functions, but the class derivedClassB specifically blocks the
 use of the "doSomething()" function. Attempting to call this function
 should result in a compiler error, not in a runtime exception.

 In the past, I've used exceptions to define class hierarchies like
 this. I'll define the methods that I need in the base class, and then
 I'll overload those functions in the derived classes, something like
 this:

 class derivedClassB: baseClass {
 public void doSomething() {
 throw new Exception("Cannot call doSomething from a
 derivedClassB object");
 }
 public void doSomethingSilly() {

 }
 }

 But throwing exceptions is costly, and besides, I should be able to
 know AT COMPILE TIME if I'm calling methods that shouldn't exist
 anyhow.

 I've been wishing for functionality like this for ages, and I can't
 fathom why it isn't available. It seems like it would be easy to use
 the "block" keyword to simply remove an entry from the v-table,
 wouldn't it?

Aug 13 2003
next sibling parent Jason Mills <jmills cs.mun.ca> writes:
Comments in line.

Mike Wynn wrote:
 why make base::doSomthing public if you don't want it callable from a sub
 class ??

What about you are not the designer of the base class, and can't modify it? For example, the base class could be a part of a library you are using. You want to specialize a class in the library but in such a way that some base methods just don't make sense anymore for the new subclass.
 by saying
 class Base {
     public void func() {... }
 }
 you are defining the base "interface" of your object
 (java has the "final" keyword to stop you redefining a functions in a super
 class)
 but if you realy do no want func to be called for a super class I would say
 your object heirachy is wrong somewhere, or is should be
 
 class Base {
     private void func() {... } // only callable by Base and only implemented
 here
 }
 
 or protected if you want to allow the Derived classes to access them but not
 others.
 

Aug 13 2003
prev sibling parent reply Benji Smith <dlanguage xxagg.com> writes:
On Wed, 13 Aug 2003 16:16:02 +0100, "Mike Wynn"
<mike.wynn l8night.co.uk> wrote:

why make base::doSomthing public if you don't want it callable from a sub
class ??

The example that I posted was a bit too simplistic. Let me tell you the real (well, almost real) situation in which I'm encountering this: ****************************************************************** class Node { public char[] name; public Node prevSibling; public Node nextSibling; public Node parent; public void appendChild(); public Node getChild(int index); public void removeChild(int index); } class Document: Node { public char[] version; public char[] encoding; public char[] standalone; block Node parent; } class Element: Node { public char[char[]][] attributes; } class Comment: Node { block void appendChild(); block void getChild(); block void removeChild(); } ****************************************************************** Comments, Elements, and Documents are all derived classes of the superclass Node. Documents and Elements both have children, so they both need the appendChild(), getChild, and removeChild() methods. But a comment node, which is a perfectly valid type of node, doesn't have any children, so it should be able to block these methods. It doesn't need them. Likewise, a Docment node can't have a parent, so I should be able to block the parent member. Of course, I could implement the appendChild(), removeChild(), and getChild() methods separately in both the Document class and in the Element class, but THE CODE IS ESSENTIALLY IDENTICAL, so it doesn't make any sense for me to have that code exist in both places. I moved that code to the parent class so that both derived classes can take advantage of it. And the Comment class need to descendants of the Node class, just like the Element and Document classes, so that I can handle them all polymorphically when linking to prevSibling and nextSibling. So, for my XML api, it would make my life a lot easier, it would make my object hierarchy simpler, and it would make runtime performance more predictable, if I could just block methods and members that aren't needed in a particular derived class.
but if you realy do no want func to be called for a super class I would say
your object heirachy is wrong somewhere

I anticipated that type of response, but I think it's a knee-jerk reaction that isn't necessarily correct. That's like saying "if you have to ADD member functions to a child class, maybe the class hierarchy is wrong." A derived class can _ADD_ new members to the members inherited from the parent class. A derived class can _OVERRIDE_ existing members inherited from the parent class. So why can a derived class not _BLOCK_ access to some of the members of the parent class? This seems like a perfectly logical conclusion to me. There's no reason to say that the derived class isn't logically a subclass of the parent class. But it's not EXACTLY THE SAME as its parent, and one of the ways that it should be able to differentiate itself is by blocking access to methods that are important to the parent but not to the child. Am I the only one who thinks this is silly?
Aug 13 2003
next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
In article <sivkjv0nadkrv2oebehn6c0fv33ebjdo1l 4ax.com>, Benji Smith says...
On Wed, 13 Aug 2003 16:16:02 +0100, "Mike Wynn"
<mike.wynn l8night.co.uk> wrote:

why make base::doSomthing public if you don't want it callable from a sub
class ??

The example that I posted was a bit too simplistic. Let me tell you the real (well, almost real) situation in which I'm encountering this: ****************************************************************** class Node { public char[] name; public Node prevSibling; public Node nextSibling; public Node parent; public void appendChild(); public Node getChild(int index); public void removeChild(int index); } class Document: Node { public char[] version; public char[] encoding; public char[] standalone; block Node parent; } class Element: Node { public char[char[]][] attributes; } class Comment: Node { block void appendChild(); block void getChild(); block void removeChild(); }

What happens when you do this: Node n = new Comment(); n.appendChild(); // Legal for Node
Aug 13 2003
prev sibling next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Benji Smith" <dlanguage xxagg.com> wrote in message
news:sivkjv0nadkrv2oebehn6c0fv33ebjdo1l 4ax.com...
 On Wed, 13 Aug 2003 16:16:02 +0100, "Mike Wynn"
 <mike.wynn l8night.co.uk> wrote:

why make base::doSomthing public if you don't want it callable from a sub
class ??


class Node {} class Doc : Node {} class NodeWithParent : Node { } class Foo : NodeWithParent { } etc or use interfaces; class Node { } interface IHasParent {} interface IHasSibling : IHasParent {} // how can you have siblings if you ain't got a parent interface IHasChildren {} // how can you have siblings if you ain't got a parent etc ... if you want to see the ways ppl solve this look at gui libs, (C++ : TurboVision,MFC, WTL, WxWindows, VGUI, BeOS API) (Delphi: VCL) (Java: AWT, Swing, IFC (if you can find it, was netscaps Swing before swing on top of the AWT, the Eclipse/IBM SWT) ) you have a similar issue, to the gui questions of ... should componant be able to "draw" on itself, and should it have children, and where if any do the layout managers connect to.
 The example that I posted was a bit too simplistic. Let me tell you
 the real (well, almost real) situation in which I'm encountering this:

 ******************************************************************
 class Node {
 public char[] name;
 public Node prevSibling;
 public Node nextSibling;
 public Node parent;
 public void appendChild();
 public Node getChild(int index);
 public void removeChild(int index);
 }

 class Document: Node {
 public char[] version;
 public char[] encoding;
 public char[] standalone;
 block Node parent;
 }

 class Element: Node {
 public char[char[]][] attributes;
 }

 class Comment: Node {
 block void appendChild();
 block void getChild();
 block void removeChild();
 }
 ******************************************************************

 Comments, Elements, and Documents are all derived classes of the
 superclass Node. Documents and Elements both have children, so they
 both need the appendChild(), getChild, and removeChild() methods. But
 a comment node, which is a perfectly valid type of node, doesn't have
 any children, so it should be able to block these methods. It doesn't
 need them.

 Likewise, a Docment node can't have a parent, so I should be able to
 block the parent member.

 Of course, I could implement the appendChild(), removeChild(), and
 getChild() methods separately in both the Document class and in the
 Element class, but THE CODE IS ESSENTIALLY IDENTICAL, so it doesn't
 make any sense for me to have that code exist in both places. I moved
 that code to the parent class so that both derived classes can take
 advantage of it.

 And the Comment class need to descendants of the Node class, just like
 the Element and Document classes, so that I can handle them all
 polymorphically when linking to prevSibling and nextSibling.

 So, for my XML api, it would make my life a lot easier, it would make
 my object hierarchy simpler, and it would make runtime performance
 more predictable, if I could just block methods and members that
 aren't needed in a particular derived class.

but if you realy do no want func to be called for a super class I would


your object heirachy is wrong somewhere

I anticipated that type of response, but I think it's a knee-jerk reaction that isn't necessarily correct. That's like saying "if you have to ADD member functions to a child class, maybe the class hierarchy is wrong." A derived class can _ADD_ new members to the members inherited from the parent class. A derived class can _OVERRIDE_ existing members inherited from the parent class. So why can a derived class not _BLOCK_ access to some of the members of the parent class? This seems like a perfectly logical conclusion to me.

because your saying this is not quite a subclass! if you block a member it is no longer passable as its base class because it have missing functionality.
 There's no reason to say that the derived class isn't logically a
 subclass of the parent class. But it's not EXACTLY THE SAME as its
 parent, and one of the ways that it should be able to differentiate
 itself is by blocking access to methods that are important to the
 parent but not to the child.

 Am I the only one who thinks this is silly?

no your just experiancing one of the problems with single inheritance and static typing, with MI or dynamic typing its all possible but the price is performance. "your object heirachy is wrong" may be a knee-jerk reaction, but you should question if your heirachy is right and why `Doc` can not have a parent (obviously there has to be a Node with a "null" parent, or no parent, which also means that it can not have any siblings too ) D has class invariants so Doc class must always have a null parent, all you have to do is put an assert in the "setParent method of Doc to make sure its parent can not be set, and write your code so that it can deal with getParent() returning null (i.e. no parent).
Aug 13 2003
parent reply Benji Smith <dlanguage xxagg.com> writes:
On Wed, 13 Aug 2003 22:21:40 +0100, "Mike Wynn"
<mike.wynn l8night.co.uk> wrote:

"Benji Smith" <dlanguage xxagg.com> wrote in message
news:sivkjv0nadkrv2oebehn6c0fv33ebjdo1l 4ax.com...
 On Wed, 13 Aug 2003 16:16:02 +0100, "Mike Wynn"
 <mike.wynn l8night.co.uk> wrote:

why make base::doSomthing public if you don't want it callable from a sub
class ??


class Node {} class Doc : Node {} class NodeWithParent : Node { } class Foo : NodeWithParent { } etc or use interfaces; class Node { } interface IHasParent {} interface IHasSibling : IHasParent {} // how can you have siblings if you ain't got a parent interface IHasChildren {} // how can you have siblings if you ain't got a parent etc ...

What I'd really like to do is to create a class hierarchy like this... Node NodeWithChildren: Node NodeWithParent: Node Document:NodeWithChildren Element:NodeWithParent, NodeWithChildren Comment:NodeWithParent Text:NodeWithParent CDataSection:NodeWithParent ProcessingInstruction:NodeWithParent ...but it would require mulitiple inheritance, and apparantly it becomes much more difficult to write a compiler if it uses multiple inheritance. I suppose that NodeWithParent and NodeWithChildren could be interfaces (IHasParent and IHasChildren) rather than classes, but then I have to put the implementations of the parent-handling and children-handling methods into all of the individual classes. So, I would need to copy the parent-handling methods (which would be exactly the same in every class that uses them) five different times! The first rule of programming that I learned is DON'T HAVE THE SAME CODE IN MULTIPLE PLACES. I think that rule is more important than having a perfect object hierarchy. So interfaces are definitely a no-win situation for me. As far as I'm concerned interfaces are mostly useful when you need to enforce a particular set of methods onto other people who will be implementing classes that will interface with your code in a particular way. But using interfaces (in this situation) won't help ME keep my own code small, manageable, and robust.
"your object heirachy is wrong" may be a knee-jerk reaction, but you should
question if your heirachy is right and why `Doc` can not have a parent
(obviously there has to be a Node with a "null" parent, or no parent, which
also means that it can not have any siblings too )
D has class invariants so Doc class must always have a null parent, all you
have to do is put an assert in the "setParent method of Doc to make sure its
parent can not be set, and write your code so that it can deal with
getParent() returning null (i.e. no parent).

It looks like I'll be sticking with my original strategy, throwing exceptions from the method implementations of descendant classes that shouldn't have those methods anyhow. So if you call... myComment.appendChild(myNode); ...it will throw a... DomException("You cannot call appendChild() from a Comment object"); It's ugly, and I don't like it, but at least it keeps me from copying the same code into five different classes. Honestly, there's got to be a better solution to this.
Aug 14 2003
next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
In article <hh6njvsmtqduiuihdels8nrmvps8ju8p27 4ax.com>, Benji Smith says...
What I'd really like to do is to create a class hierarchy like this...

Node
NodeWithChildren: Node
NodeWithParent: Node
Document:NodeWithChildren
Element:NodeWithParent, NodeWithChildren
Comment:NodeWithParent
Text:NodeWithParent
CDataSection:NodeWithParent
ProcessingInstruction:NodeWithParent

...but it would require mulitiple inheritance...

Might be possible with templates template AddParentT(T) { class WithParent : T { Node parent; } } template AddChildrenT(T) { class WithChildren : T { appendChild(); getChild() } } class Node {} class Document : instance AddChildrenT(Node).WithChildren {} class Element : instance AddParentT( instance AddChildrenT(Node).WithChildren).WithParent { } class Comment : instance AddParentT(Node).WithParent { } class Text : instance AddParentT(Node).WithParent { }
Aug 14 2003
prev sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Benji Smith" <dlanguage xxagg.com> wrote in message
news:hh6njvsmtqduiuihdels8nrmvps8ju8p27 4ax.com...
 On Wed, 13 Aug 2003 22:21:40 +0100, "Mike Wynn"
 <mike.wynn l8night.co.uk> wrote:

"Benji Smith" <dlanguage xxagg.com> wrote in message
news:sivkjv0nadkrv2oebehn6c0fv33ebjdo1l 4ax.com...
 On Wed, 13 Aug 2003 16:16:02 +0100, "Mike Wynn"
 <mike.wynn l8night.co.uk> wrote:

why make base::doSomthing public if you don't want it callable from a




class ??


class Node {} class Doc : Node {} class NodeWithParent : Node { } class Foo : NodeWithParent { } etc or use interfaces; class Node { } interface IHasParent {} interface IHasSibling : IHasParent {} // how can you have siblings if you ain't got a parent interface IHasChildren {} // how can you have siblings if you ain't got a parent etc ...

What I'd really like to do is to create a class hierarchy like this... Node NodeWithChildren: Node NodeWithParent: Node Document:NodeWithChildren Element:NodeWithParent, NodeWithChildren Comment:NodeWithParent Text:NodeWithParent CDataSection:NodeWithParent ProcessingInstruction:NodeWithParent ...but it would require mulitiple inheritance, and apparantly it becomes much more difficult to write a compiler if it uses multiple inheritance. I suppose that NodeWithParent and NodeWithChildren could be interfaces (IHasParent and IHasChildren) rather than classes, but then I have to put the implementations of the parent-handling and children-handling methods into all of the individual classes. So, I would need to copy the parent-handling methods (which would be exactly the same in every class that uses them) five different times! The first rule of programming that I learned is DON'T HAVE THE SAME CODE IN MULTIPLE PLACES. I think that rule is more important than having a perfect object hierarchy.

mixin's are what you want. you can use templates for "has children" or "group" class but D does not support lightwight templating (that is a template where the params are all objects so instances are all the same code (different cast on systems that require a cast like java) // you could try .. template has_children( Base : Node ) { class Group : Base, IGroup { add the child handleing code here. } } in d asfaik you have to use an interface for the group methods to gain acess to them as there is no way to cast to `Group` as you dont know the type it was created with a language feature that would help is lightweight templating, where the templated types are all Object (or restricted to a subclass of) and the compiler knows the type that the template related to (great for collections) so Stack<Node> is subclass of Stack<Object> which is a subclass of Stack. (like Java arrays are, [with the required runtime type checking compiled in automatically] kind of hybrid dynamic typechecking on a statically typed lang. the above example could be although code like lightweight_template(Base : Node) class Group : Base{ Node addChildren(); } } although there are issues here if you try to make a group of a group where as lightweight_template(Base : Node) class Owned : Node { Base getParent(); } } can be Owned<Owned<Doc>>
 So interfaces are definitely a no-win situation for me. As far as I'm
 concerned interfaces are mostly useful when you need to enforce a
 particular set of methods onto other people who will be implementing
 classes that will interface with your code in a particular way. But
 using interfaces (in this situation) won't help ME keep my own code
 small, manageable, and robust.

"your object heirachy is wrong" may be a knee-jerk reaction, but you


question if your heirachy is right and why `Doc` can not have a parent
(obviously there has to be a Node with a "null" parent, or no parent,


also means that it can not have any siblings too )
D has class invariants so Doc class must always have a null parent, all


have to do is put an assert in the "setParent method of Doc to make sure


parent can not be set, and write your code so that it can deal with
getParent() returning null (i.e. no parent).

It looks like I'll be sticking with my original strategy, throwing exceptions from the method implementations of descendant classes that shouldn't have those methods anyhow. So if you call... myComment.appendChild(myNode); ...it will throw a... DomException("You cannot call appendChild() from a Comment object"); It's ugly, and I don't like it, but at least it keeps me from copying the same code into five different classes. Honestly, there's got to be a better solution to this.

do tree classes think about how to describe a binary tree each node, has two nodes left or right, which can be either a parent_node or a leaf_node; often you want a parent_node to only no data or a small amount of data a leaf is a node can not have children, but usually has a data item. its not perfect but what is ... but only requires the code writing once, instead of blocking the base class defines all the possible ops, but throws an exception if the sub class does not implemtent them (realy what is required is dynamic typing, but your using a statically types lang so you have to work around the problem) if you realy can't handle static typing, use perl, self or lua! class Node { Node getLeft() { throws NotValidOpException("can't do getLeft on this type"); } Node getRight() { throws NotValidOpException("can't do getRight on this type"); } void setLeft( Node n ) { throws NotValidOpException("can't do setLeft on this type"); } void setRight( Node n ) { throws NotValidOpException("can't do setRight on this type"); } int getType() { throws NotValidOpException("can't do getType on this type"); } Object getValue() { throws NotValidOpException("can't do getValue on this type"); } } class Parent : Node { Node l, r; Node getLeft() { return l; } Node getRight() { return r; } Node setLeft( Node n ) { l = n; } Node setRight( Node n ) { r = n; } } class Leaf : Node { int t; Object v; int getType() { return t; } Object getValue() { return v; } }
Aug 14 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Look at it this way.

If you have this situation:

class A
{
    public foo() {}
}

class B : A
{
    block foo() {}
}

void bar(A a) { a.foo(); }

bar(new B);

What do you suppose should happen?

Are B's now no longer "compatible" with A's interface?  If so, it isn't a
"derived" class in the proper sense.

Think what would happen if you "block" a member variable from class A in
class B instead.  The memory layout no longer matches, and anything
expecting an A will probably fail if you give it a B instead.

With methods, it will still break, but logically instead of physically.

Deriving from a class is like a form of contract, demanding the child class
remain compatible with the parent.  You're asking to be able to violate that
contract, and have the compiler figure it out and realize it can no longer
be cast to the base class interface?

If you just don't want to expose a base class member in the derived class,
just redeclare it private (however in D you probably have to provide an
implementation for it, probably should add a call to the super function so
virtual calls thru the still-public parent interface work right).  I do not
think D automates this like C++ does.

It seems to be a better solution would be mixins.

******************************************************************
class Parent
{
public void appendChild();
public Node getChild(int index);
public void removeChild(int index);
}

class Child
{
public Node parent;
}

class Node {
public char[] name;
public Node prevSibling;
public Node nextSibling;
}

class Document: Node, mixin Parent {
public char[] version;
public char[] encoding;
public char[] standalone;
}

class Element: Node, mixin Parent, mixin Child {
public char[char[]][] attributes;
}

class Comment: Node, mixin Child {
}
******************************************************************

However you'd need a form of dynamic cast to decide if a given Node is
capable of being a Parent, or being a Child.

Walter seems against multiple inheritance, however, so I doubt anything like
this will make it into D.

However you can still do it "right" using good old fashioned class design.
;)

******************************************************************
class Node {
public char[] name;
public Node prevSibling;
public Node nextSibling;
}

class ParentNode: Node
{
public void appendChild();
public Node getChild(int index);
public void removeChild(int index);
}

class ChildNode : Node
{
public Node parent;
}


class ParentChildNode: ParentNode
{
public Node parent;
}

class Document: ParentNode
{
public char[] version;
public char[] encoding;
public char[] standalone;
}

class Element: ParentChildNode
{
public char[char[]][] attributes;
}

class Comment: ChildNode
{
}
******************************************************************

However as you can guess, this solution is brittle, since it takes work to
keep the class hierarchy in good shape as its structure changes.  You can
see the beginnings of this in how I built ParentChildNode.  Ideally
ParentChildNode would be both a ParentNode *and* a ChildNode.  It's a
Pandora's Box.

Sharing code seems like such a worthy cause, but it can cause lots of
problems.

Sean

"Benji Smith" <dlanguage xxagg.com> wrote in message
news:sivkjv0nadkrv2oebehn6c0fv33ebjdo1l 4ax.com...
 On Wed, 13 Aug 2003 16:16:02 +0100, "Mike Wynn"
 <mike.wynn l8night.co.uk> wrote:

why make base::doSomthing public if you don't want it callable from a sub
class ??

The example that I posted was a bit too simplistic. Let me tell you the real (well, almost real) situation in which I'm encountering this: ****************************************************************** class Node { public char[] name; public Node prevSibling; public Node nextSibling; public Node parent; public void appendChild(); public Node getChild(int index); public void removeChild(int index); } class Document: Node { public char[] version; public char[] encoding; public char[] standalone; block Node parent; } class Element: Node { public char[char[]][] attributes; } class Comment: Node { block void appendChild(); block void getChild(); block void removeChild(); } ****************************************************************** Comments, Elements, and Documents are all derived classes of the superclass Node. Documents and Elements both have children, so they both need the appendChild(), getChild, and removeChild() methods. But a comment node, which is a perfectly valid type of node, doesn't have any children, so it should be able to block these methods. It doesn't need them. Likewise, a Docment node can't have a parent, so I should be able to block the parent member. Of course, I could implement the appendChild(), removeChild(), and getChild() methods separately in both the Document class and in the Element class, but THE CODE IS ESSENTIALLY IDENTICAL, so it doesn't make any sense for me to have that code exist in both places. I moved that code to the parent class so that both derived classes can take advantage of it. And the Comment class need to descendants of the Node class, just like the Element and Document classes, so that I can handle them all polymorphically when linking to prevSibling and nextSibling. So, for my XML api, it would make my life a lot easier, it would make my object hierarchy simpler, and it would make runtime performance more predictable, if I could just block methods and members that aren't needed in a particular derived class.
but if you realy do no want func to be called for a super class I would


your object heirachy is wrong somewhere

I anticipated that type of response, but I think it's a knee-jerk reaction that isn't necessarily correct. That's like saying "if you have to ADD member functions to a child class, maybe the class hierarchy is wrong." A derived class can _ADD_ new members to the members inherited from the parent class. A derived class can _OVERRIDE_ existing members inherited from the parent class. So why can a derived class not _BLOCK_ access to some of the members of the parent class? This seems like a perfectly logical conclusion to me. There's no reason to say that the derived class isn't logically a subclass of the parent class. But it's not EXACTLY THE SAME as its parent, and one of the ways that it should be able to differentiate itself is by blocking access to methods that are important to the parent but not to the child. Am I the only one who thinks this is silly?

Aug 14 2003
prev sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
"Benji Smith" <dlanguage xxagg.com> a écrit dans le message de
news:h2ikjv8f8bf6h09fnamt6ivuehqb5401vv 4ax.com...
 Here's an idea that I've been aching for in several different
 languages: method blocking.

 I often create base classes that will have lots of different kinds of
 derived classes. To avoid duplicating code, I put all the method
 definitions in the base class, so that they can be inherited by the
 derived classes that really need them. But not all of the derived
 classes should have access to all of the methods in the parent class,
 and I'd like to block them.

 Take a look at this code:

 class baseClass {
 public void doSomething() {
 ...
 }
 }
 class derivedClassA: baseClass {
 public void doSomethingFun() {

 }
 }
 class derivedClassB: baseClass {
 block void doSomething();
 }

In pratice, if someone want to block one method then the design is probably bad... Also block a method does not works well with public inheritance since we can access the method with a base pointer but not a derived one. Thus, it would have to be combined with another inheritance (protected or private). I don't know if D check access after having found a method. If so then it would be usefull to have a modifier "hidden" so that the compiler would not consider the object as one of its base type (it would just allows overring virtual methods).
Aug 16 2003