How should I write some code that would have an effect similar to what:
interface P
{  this(ulong ndx);
   ulong   fset();
}

would have if it were a legal construct?

The "constructor" needs to return an instance of the class that implements it.

Charles D Hixson wrote:
> How should I write some code that would have an effect similar to what:
> interface P
> {  this(ulong ndx);
>    ulong   fset();
> }
> 
> would have if it were a legal construct?
> 
> The "constructor" needs to return an instance of the class that implements it.
I think you have to use the factory pattern:

interface P
{
	ulong fset();
}

interface PFactory
{
	P create();
}

Charles D Hixson wrote:
> How should I write some code that would have an effect similar to what:
> interface P
> {  this(ulong ndx);
>    ulong   fset();
> }
> 
> would have if it were a legal construct?
> 
> The "constructor" needs to return an instance of the class that implements it.

It strikes me as odd that you would want to do this. (I would have to see the usage though before I would say you shouldn't.) As I understand it the intention of Interfaces is that the underlying implementation is /totally/ hidden. If there is some action that the class needs to do at instancing time, then that should be apparent to the person coding the class and done by them.

OTOH, if the "this" function is doing something like registering the class with some sort of global catalog, you might have need for something like that. However I would make the registration action associated with the catalog and not the Objects

/******
Objects implementing P must register with the Catalog
******/
interface P
{  this(ulong);
   ulong   fset();
}

class Catalog
{
	void Add(P);
	void Remove(P);
}

Catalog cat;

class PO : P
{
	ulong fset(){...}


	this(ulong f)
	{
		...

		cat.Add(cast(P)this);
	}


	~this()
	{
		cat.Remove(cast(P)this);
	}

	// OR

	/****************
		ALWAYS registrar this class with the Catalog
	****************/
}

BCS wrote:
> Charles D Hixson wrote:
>> How should I write some code that would have an effect similar to what:
>> interface P
>> {  this(ulong ndx);
>>    ulong   fset();
>> }
>>
>> would have if it were a legal construct?
>>
>> The "constructor" needs to return an instance of the class that implements it.
> 
> It strikes me as odd that you would want to do this. (I would have to see the usage though before I would say you shouldn't.) As I understand it the intention of Interfaces is that the underlying implementation is /totally/ hidden. If there is some action that the class needs to do at instancing time, then that should be apparent to the person coding the class and done by them.
> 
> OTOH, if the "this" function is doing something like registering the class with some sort of global catalog, you might have need for something like that. However I would make the registration action associated with the catalog and not the Objects
> 
> /******
> Objects implementing P must register with the Catalog
> ******/
> interface P
> {  this(ulong);
>    ulong   fset();
> }
> 
> class Catalog
> {
>     void Add(P);
>     void Remove(P);
> }
> 
> Catalog cat;
> 
> class PO : P
> {
>     ulong fset(){...}
> 
> 
>     this(ulong f)
>     {
>         ...
> 
>         cat.Add(cast(P)this);
>     }
> 
> 
>     ~this()
>     {
>         cat.Remove(cast(P)this);
>     }
> 
>     // OR
> 
>     /****************
>         ALWAYS registrar this class with the Catalog
>     ****************/
> }
> 

That's essentially what I wanted to do (with variations...it's to disk, and the methods are save and restore)...but the interface is invalid!

I guess what I'm going to need to do is derive everything from a common ancestral class...and that means that the derived classes CAN'T descend from anything else, *sigh*.  The common ancestor will need to be a totally abstract class, so I thought an interface would be a better choice, but it looks like there's no way to make it work...because they've all got to implement a common constructor type, and the compiler has to KNOW that they do so.

> I guess what I'm going to need to do is derive everything from a common ancestral class...and that means that the derived classes CAN'T descend from anything else, *sigh*.  The common ancestor will need to be a totally abstract class, so I thought an interface would be a better choice, but it looks like there's no way to make it work...because they've all got to implement a common constructor type, and the compiler has to KNOW that they do so.

Hmm.. why exactly do you need a common constructor type? When you create an object, you must know its exact type (and constructors) anyway, so how does it matter?


xs0

xs0 wrote:
> 
>> I guess what I'm going to need to do is derive everything from a common ancestral class...and that means that the derived classes CAN'T descend from anything else, *sigh*.  The common ancestor will need to be a totally abstract class, so I thought an interface would be a better choice, but it looks like there's no way to make it work...because they've all got to implement a common constructor type, and the compiler has to KNOW that they do so.
> 
> Hmm.. why exactly do you need a common constructor type? When you create an object, you must know its exact type (and constructors) anyway, so how does it matter?
> 
> 
> xs0
I think maybe you're right.  If so, then I probably can't do what I want to do in D.  I'd been thinking that if I just worked ahead I'd be able to solve the problem of "somehow" using the thing that I'd created, if I could only create it. And I could refer to it from the ancestral reference.  But I hadn't been able to figure out the details, so I was just trying to work my way forwards.  But maybe I can't do it at all.

(Well, this isn't literally true, of course.  I could always define everything in terms of a Vector of bytes.  But in so doing I give up most of what makes Computer Languages different from assembler.)

I guess that means that it's back to Python.  At least I can drop into Pyrex when I hit places that are performance bottlenecks.  Or even into C.  (I may truly dislike C with it's wild use of pointers, but it *is* possible.  And it's about the same speed as D. [I don't really believe that shootout that says that D is faster.  How *can* it be?])

So, the answer is that a constructor signature cannot be part of an interface?

We must use always the factory pattern?

---
Paolo

xs0 wrote:
> 
>> I guess what I'm going to need to do is derive everything from a common ancestral class...and that means that the derived classes CAN'T descend from anything else, *sigh*.  The common ancestor will need to be a totally abstract class, so I thought an interface would be a better choice, but it looks like there's no way to make it work...because they've all got to implement a common constructor type, and the compiler has to KNOW that they do so.
> 
> Hmm.. why exactly do you need a common constructor type? When you create an object, you must know its exact type (and constructors) anyway, so how does it matter?
> 
> 
> xs0

Paolo Invernizzi wrote:
> So, the answer is that a constructor signature cannot be part of an interface?
> 
> We must use always the factory pattern?

Well, as far as I can tell, you can't create a new object without a new expression, in which you need to state the exact type, so even if you could specify a constructor signature in an interface, you still couldn't generically create an object.

If you could do it, though, what would the rest of the code look like? (I think you can't code around explicitly listing types somewhere, so I'm interested what you feel would be gained).


xs0

Charles D Hixson wrote:
> xs0 wrote:
> 
>>
>>> I guess what I'm going to need to do is derive everything from a common ancestral class...and that means that the derived classes CAN'T descend from anything else, *sigh*.  The common ancestor will need to be a totally abstract class, so I thought an interface would be a better choice, but it looks like there's no way to make it work...because they've all got to implement a common constructor type, and the compiler has to KNOW that they do so.
>>
>>
>> Hmm.. why exactly do you need a common constructor type? When you create an object, you must know its exact type (and constructors) anyway, so how does it matter?
>>
>>
>> xs0
> 
> I think maybe you're right.  If so, then I probably can't do what I want to do in D.  I'd been thinking that if I just worked ahead I'd be able to solve the problem of "somehow" using the thing that I'd created, if I could only create it. And I could refer to it from the ancestral reference.  But I hadn't been able to figure out the details, so I was just trying to work my way forwards.  But maybe I can't do it at all.
> 
> (Well, this isn't literally true, of course.  I could always define everything in terms of a Vector of bytes.  But in so doing I give up most of what makes Computer Languages different from assembler.)
> 
> I guess that means that it's back to Python.  At least I can drop into Pyrex when I hit places that are performance bottlenecks.  Or even into C.  (I may truly dislike C with it's wild use of pointers, but it *is* possible.  And it's about the same speed as D. [I don't really believe that shootout that says that D is faster.  How *can* it be?])

(Ignore this if I am misreading you - David)

I don't quite 'get' what you are trying to accomplish(not technically but in a design sense).

Unless you are attempting to add compiled classes at runtime, I would be surprised if D could not accomplish what you are doing.

To create an object which has a known constructor, use a template function/object....but there is a better way.

Have your objects created with no argument constructors then configured using a common method.  I have a text format(XML lite) I use in which each node is a 'constructor' for an object.  Then the children of the node are passed to the config() method of the object.  In this way I can have many similar objects which are combined in different ways.

Is this close to what you are trying?
-David

David Medlock wrote:
> Unless you are attempting to add compiled classes at runtime, I would be surprised if D could not accomplish what you are doing.

And if you want to add compiled classes at runtime, you'll have to wait for DDL to be released -- but D will be able to accomplish it . <g>