I want an array of different classes of objects. I tried to
subsume the differences by extending the classes under a single
interface/abstract class/super class (3 different approaches) all
to no avail as I could not access the public variables of the
instantiated classes while storing them in an array defined by
the interface/super class.

interface Widget{
void draw();
}

class Button : Widget{
public int vertCount;

void draw(){}
}

class Cursor : Widget{
public int vertCount;

void draw(){}
}

//called from
Widget[] widgets;
widgets~=new Button();
widgets~=new Cursor();

foreach(Widget w; widgets){
writeln(w.vertCount);
}
//Error: no property 'vertCount' for type 'Widget.Widget'


A solution that should work is to dump extending the classes and
make an array of void pointers that point, some to Button objects
and some to Cursors but I do not know the syntax for doing this,
or even if it is possible to have an array of pointers pointing
at different classes of objects. I should think it should be
possible given that, on a 32 bit machine, pointers are all 32 bit
ints so it is basically an array of ints that is being created,
only those ints contain the address of a bunch of different types
of objects.

On Mon, May 14, 2012 at 08:40:30PM +0200, Stephen Jones wrote:
> I want an array of different classes of objects. I tried to subsume the differences by extending the classes under a single interface/abstract class/super class (3 different approaches) all to no avail as I could not access the public variables of the instantiated classes while storing them in an array defined by the interface/super class.
[...]

Every class derives from Object, so an Object[] should do what you want.

Also, if you need to access public variables of a derived class, you need to downcast:

	// Suppose this is your class heirarchy
	class Base { int x; }
	class Derived1 : Base { int y; }
	class Derived2 : Base { int z; }

	// Here's how you can put derived objects in a single array
	auto d1 = new Derived1();
	auto d2 = new Derived2();
	Base[] o = [d1, d2];

	// You can directly access base class members:
	o[0].x = 123;
	o[1].x = 234;

	// Here's how to downcast to a derived type
	Derived1 dp = cast(Derived1) o[0];
	if (dp !is null) {
		dp.y = 345;
	}

	Derived2 dp2 = cast(Derived2) o[1];
	if (dp2 !is null) {
		dp.z = 456;
	}

Note that the if statements are necessary, since when downcasting you don't know if the given Base object is actually an instance of that particular derived object. If you tried cast(Derived1) o[1], it will return null because o[1] is not an instance of Derived1.


T

-- 
Nothing in the world is more distasteful to a man than to take the path that leads to himself. -- Herman Hesse

On Monday, 14 May 2012 at 19:04:46 UTC, H. S. Teoh wrote:
> On Mon, May 14, 2012 at 08:40:30PM +0200, Stephen Jones wrote:
>> I want an array of different classes of objects. I tried to
>> subsume the differences by extending the classes under a single
>> interface/abstract class/super class (3 different approaches) all
>> to no avail as I could not access the public variables of the
>> instantiated classes while storing them in an array defined by
>> the interface/super class.
> [...]
>
> Every class derives from Object, so an Object[] should do what you want.
>
> Also, if you need to access public variables of a derived class, you
> need to downcast:
>
> 	// Suppose this is your class heirarchy
> 	class Base { int x; }
> 	class Derived1 : Base { int y; }
> 	class Derived2 : Base { int z; }
>
> 	// Here's how you can put derived objects in a single array
> 	auto d1 = new Derived1();
> 	auto d2 = new Derived2();
> 	Base[] o = [d1, d2];
>
> 	// You can directly access base class members:
> 	o[0].x = 123;
> 	o[1].x = 234;
>
> 	// Here's how to downcast to a derived type
> 	Derived1 dp = cast(Derived1) o[0];
> 	if (dp !is null) {
> 		dp.y = 345;
> 	}
>
> 	Derived2 dp2 = cast(Derived2) o[1];
> 	if (dp2 !is null) {
> 		dp.z = 456;
> 	}
>
> Note that the if statements are necessary, since when downcasting you
> don't know if the given Base object is actually an instance of that
> particular derived object. If you tried cast(Derived1) o[1], it will
> return null because o[1] is not an instance of Derived1.
>
>
> T

Using Object gives exactly the same problem as the Object super class does not have vcount variable. Casting is not a solution because the reason for throwing different sorts of widgets into a single array was so I did not have to track what each type of object was; not tracking what each object in the array is I have no means of knowing what to cast each Widget in the array to.

If some one knows void pointer syntax that would be helpful. As I understand it there is a type called size_t that takes the address of as a a value. Can I make an array of these and simply initialize each with &button1, &cursor, etc? Also, how is size_t freed?

On Wednesday, 16 May 2012 at 02:01:25 UTC, Stephen Jones wrote:
> Using Object gives exactly the same problem as the Object super class does not have vcount variable. Casting is not a solution because the reason for throwing different sorts of widgets into a single array was so I did not have to track what each type of object was; not tracking what each object in the array is I have no means of knowing what to cast each Widget in the array to.

You'd just try to cast each object into the classes you want. Like he said, it'll be null if the casting failed. Otherwise, it'll be the object and you can get the vcount.

However, I have to ask ... is it that all Widgets need to have this vcount? If so, the proper way to do this is user-defined properties:
http://dlang.org/property.html

So your Widget class might look like this:
class Widget {
    public @property int vertCount();    // getter
    public @property int vertCount(int); // setter
    void draw(){}
}


> If some one knows void pointer syntax that would be helpful. As I understand it there is a type called size_t that takes the address of as a a value. Can I make an array of these and simply initialize each with &button1, &cursor, etc? Also, how is size_t freed?

This is _not_ a solution you want at all. Converting pointers to integers in D is undefined behavior and size_t is not a type for that (it's used to hold indices for arrays and such).

If you convert a pointer to an int and get rid of the pointer, the Garbage Collector will not see any references to your object anymore and will reap your object.

On 05/15/2012 07:01 PM, Stephen Jones wrote:

> Using Object gives exactly the same problem as the Object super class
> does not have vcount variable.

But Object is better than void* because the latter has no safety and completely unusable. All you can do with a void* is to cast it back to its own type. If you don't keep type information somehow, nobody knows what the original type was.

> Casting is not a solution

That is the only solution. It may be somehow wrapped, but you must cast void* to a useful type first.

> because the
> reason for throwing different sorts of widgets into a single array was
> so I did not have to track what each type of object was;

Yeah, great! That's polymorphism. Great. You keep a Widget[] and use it.

> not tracking
> what each object in the array is I have no means of knowing what to cast
> each Widget in the array to.

Exactly! :) Either you or the compiler must keep track of it. void* removes any trace of type information.

> If some one knows void pointer syntax that would be helpful.

import std.stdio;

void main()
{
    int i;
    double d;

    void*[] array;
    array ~= cast(void*)&i;
    array ~= cast(void*)&d;

    foreach (address; array) {
        writeln("I don't know what type of object is at ", address);
    }
}

> As I
> understand it there is a type called size_t that takes the address of as
> a a value.

No. size_t is suitable to represent concepts like size, quantity, etc. Concepts that are supposed to be never less than zero.

> Can I make an array of these and simply initialize each with
> &button1, &cursor, etc? Also, how is size_t freed?

You can but it would make no sense:

import std.stdio;

void main()
{
    int i;
    double d;

    size_t[] array;
    array ~= cast(size_t)&i;
    array ~= cast(size_t)&d;

    foreach (size; array) {
        writeln("I don't know what to do with this amount: ", size);
    }
}

Getting back to your original question, here is another solution where Widget is a class (not an interface) that has a vertCount member. It makes it necessary that the subclasses construct it with that information:

import std.stdio;

class Widget{
    abstract void draw();

    size_t vertCount;

    this(size_t vertCount)
    {
        this.vertCount = vertCount;
    }
}

class Button : Widget{
    override void draw(){}

    this()
    {
        super(100);
    }
}

class Cursor : Widget{
    override void draw(){}

    this()
    {
        super(200);
    }
}

void main()
{
    Widget[] widgets;
    widgets~=new Button();
    widgets~=new Cursor();

    foreach(Widget w; widgets){
        writeln(w.vertCount);
    }
}

Ali

-- 
D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html

On Wed, May 16, 2012 at 04:01:23AM +0200, Stephen Jones wrote: [...]
> Using Object gives exactly the same problem as the Object super class does not have vcount variable. Casting is not a solution because the reason for throwing different sorts of widgets into a single array was so I did not have to track what each type of object was; not tracking what each object in the array is I have no means of knowing what to cast each Widget in the array to.

If you did not know what type each object was, how do you know they have a vcount variable?

If you _do_ know that they have a vcount variable, that means you know what type to downcast to. If there is more than one subclass with a vcount variable, that's an indication that you want to factor it into a common base class that gives a unified access to it, in which case you'd downcast to the common base class.


> If some one knows void pointer syntax that would be helpful. As I understand it there is a type called size_t that takes the address of as a a value. Can I make an array of these and simply initialize each with &button1, &cursor, etc? Also, how is size_t freed?

Void pointer does not help you at all. You can't access the vcount variable through a void pointer unless you know it's a particular type that has such a variable -- you'd have to cast the void pointer to that type first. And in that case, you might as well be downcasting instead because it's type-safe. Blindly casting a void pointer into a particular type because you _think_ that's what it is, is a recipe for disaster when later on your list changes and the void pointer no longer points to what you think it points to.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.

Am 14.05.2012 20:40, schrieb Stephen Jones:

Ali Çehreli post got your answer - see the last example of the post
news://news.digitalmars.com:119/jov3gn$2vtg$1@digitalmars.com

but first: try to understand how the base-class, interface stuff realy works - you will got the same problems in every other language like C++,Java,C#,Delphi,... you just do it the wrong way

On Wednesday, 16 May 2012 at 02:55:41 UTC, H. S. Teoh wrote:
> On Wed, May 16, 2012 at 04:01:23AM +0200, Stephen Jones wrote:
> [...]
>> Using Object gives exactly the same problem as the Object super
>> class does not have vcount variable. Casting is not a solution
>> because the reason for throwing different sorts of widgets into a
>> single array was so I did not have to track what each type of object
>> was; not tracking what each object in the array is I have no means
>> of knowing what to cast each Widget in the array to.
>
> If you did not know what type each object was, how do you know they have
> a vcount variable?
>
> If you _do_ know that they have a vcount variable, that means you know
> what type to downcast to. If there is more than one subclass with a
> vcount variable, that's an indication that you want to factor it into a
> common base class that gives a unified access to it, in which case you'd
> downcast to the common base class.
>
>
>> If some one knows void pointer syntax that would be helpful. As I
>> understand it there is a type called size_t that takes the address
>> of as a a value. Can I make an array of these and simply initialize
>> each with &button1, &cursor, etc? Also, how is size_t freed?
>
> Void pointer does not help you at all. You can't access the vcount
> variable through a void pointer unless you know it's a particular type
> that has such a variable -- you'd have to cast the void pointer to that
> type first. And in that case, you might as well be downcasting instead
> because it's type-safe. Blindly casting a void pointer into a particular
> type because you _think_ that's what it is, is a recipe for disaster
> when later on your list changes and the void pointer no longer points to
> what you think it points to.
>
>
> T



Ali you are right about the void pointer requiring a cast as I figured out. It does seem kind of odd that you cannot keep an array of integers that hold the start address of blocks of memory which blocks of memory contain objects such as Buttons etc. For I would have thought that the start address would hold something akin to a header telling whoever pointed at it that it was of a type, whichever type it was. And that if somebody asked for a piece of data that was in that block of memory the header would provide the index to it. But then I have to speculate about how it is things work because compiler design is not a field I am familiar with.

Ali your post above, and T your post in the other forum (Simpsons bit) is sort of what I was after. I tried both interface and abstract class but not outright super class. The problem I have with the solution is the same problem I have with header files and cpp files; in both instances you need to hunt in other files for the variable's definition. If name is a field that will contain Bart's name then it should be in the Bart class, otherwise I end up wasting time confused about some variable that has been initialized or used to initialize some other variable and not finding it in the relevant module.

Cain: My understanding is that D is based on "no proper ways of doing things" just get the job done. The use of properties when you can use public access baffles me. So long as you are careful with the namespaces why would you want to  incur function overheads that could only possibly "save" the situation if you were not careful with namespaces? Another anomaly I have never understood is why would you use multiple property calls when you could use a single function to set or get multiple items of data for the cost of a single function? It is either fashion, politics, or I am missing some piece of the puzzle.

On Wednesday, 16 May 2012 at 11:12:19 UTC, Stephen Jones wrote:
> Ali your post above, and T your post in the other forum (Simpsons bit) is sort of what I was after. I tried both interface and abstract class but not outright super class. The problem I have with the solution is the same problem I have with header files and cpp files; in both instances you need to hunt in other files for the variable's definition. If name is a field that will contain Bart's name then it should be in the Bart class, otherwise I end up wasting time confused about some variable that has been initialized or used to initialize some other variable and not finding it in the relevant module.

 But the thing about using an abstract class, and polymorphism/inheritance is the known interface is whatever the object is cast to. So the Simpson family
 you only know about string name, and object; That meaning anything that bart may have otherwise isn't accessible since that part of the code doesn't know more than what the Simpson class lets it know ahead of time. That is it. There isn't that much to look up depending on how high up/down you go. But I do hate looking up the information too..

> Cain: My understanding is that D is based on "no proper ways of doing things" just get the job done.

 I thought that was C++.... it was something like 'refuse to give in to an ounce of better control or simplicity if it may have any impact on performance and zero overhead'.... plus backwards compatibility. Besides the STL is so confusing I will likely never use it or most of C++.

 Proper ways of doing things are more how you write your code rather than the language. immutable, string, shared, scope... All these things have a 'proper way' of using them if you look. Just having an array as a fat pointer (with length) is a huge improvement that's built into the language. It's almost more 'D is so new that the proper way to make use of it isn't fully written/available'.

>Am 16.05.2012 13:12, schrieb Stephen Jones:

just throw aways your sensless void pointer or whatever idea - create a base interface or better base-class - everything else is just damn wrong

btw: all oop widget sets for c++, java or else are haveing a widget base class that works like people telling you - try looking at Qt, Delphi-VLC, C#-Windows-Forms etc. they all got an TForm, TWidget, QWidget, Forms whatever baseclass

all you need to do is to have a common interface - thats OOP all about,
if you interested (or think you need to) get into implementation details of derived classe means you don't do OOP and then you need to do casting and all this strange looking stuff - but that will also happen in every other language around - because you do/think of OOP in a wrong way