www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Interface question

reply Charles D Hixson <charleshixsn earthlink.net> writes:
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.
Aug 28 2006
next sibling parent Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
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.

interface P { ulong fset(); } interface PFactory { P create(); }
Aug 28 2006
prev sibling parent reply BCS <BCS pathlink.com> writes:
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 ****************/ }
Aug 29 2006
parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
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.
Aug 29 2006
parent reply xs0 <xs0 xs0.com> writes:
 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
Aug 30 2006
next sibling parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
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

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?])
Aug 30 2006
parent reply David Medlock <noone nowhere.com> writes:
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
Aug 31 2006
next sibling parent Don Clugston <dac nospam.com.au> writes:
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>
Aug 31 2006
prev sibling parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
David Medlock wrote:
 Charles D Hixson wrote:
 xs0 wrote:

...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

file, the type of the object (on the file) determines the desired type of the created object. This appears to require the kind of run-time parsing that Python, Smalltalk, and Ruby have...and that D doesn't. I though I'd find away around it, but the only way I found involved storing everything in a common format (very inefficient) and making all the calls through multiple layers of indirection. If I do all THAT I might as well use Python, which at least doesn't fight me every step of the way. This just isn't something that D is designed to do. You CAN do it, but it's not natural to the language, so you need to fight it every step of the way. It would probably literally be more efficient to do this in Python, because in Python a lot of the steps that I need to do have been hand optimized by people who spent lots of time figuring the optimizations. It would *CERTAINLY* be lots easier. (I can create an object by merely unpickling it. Each class will just need to implement the __getstate__ and __setstate__ methods.) And if I try to do something with an object that hasn't been defined, I can catch it with an error handler, and figure out what I need to do differently...which I can do at run time, when I can examine what the class that I'm trying to handle is, but can't do at compile time, because the class hasn't been read in. (A lot of the time what I'll want to do is return a message that means, approximately "I'm sorry Dave, I can't do that." :-) I won't want to abort the process just because a particular kind of object can't do that. Your brain doesn't dump memory when you encounter a parsing error...you recover. You don't WANT a hard fault. And you can't predict all the kinds of sensory stimuli you will receive. I can't actually be too specific about what I need in detail, because I'm still feeling my way along. I was hoping to use D because it's much more efficient ... if you can fit your requirements into what it is designed to do. I was going to start off coding a simple neural net...which I could have done in D, but that is intended to be only a small part of the project...and the major part requires the additional flexibility in the handling of persistence. It's no big thing. Every language has it's strong points and it's weak point. D has more strong points than almost any other...but they don't fit *all* of my needs. (If the interface between D and Python is reactivated, I may end up recoding lots of modules that will fit the D model into D. I *FAR* prefer it to C, or even to Pyrex [my current fallback if I need more efficiency].)
Aug 31 2006
parent reply Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
Charles D Hixson wrote:
 David Medlock wrote:
 Charles D Hixson wrote:
 xs0 wrote:

 ...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

of the object (on the file) determines the desired type of the created object. This appears to require the kind of run-time parsing that Python, Smalltalk, and Ruby have...and that D doesn't. I though I'd find away around it, but the only way I found involved storing everything in a common format (very inefficient) and making all the calls through multiple layers of indirection. If I do all THAT I might as well use Python, which at least doesn't fight me every step of the way.

you are deserializing objects, but you don't know what type they are. After you have deserialized them, you presumably want to do something with them. Am I right? So, presuming you want to do something with them, you can probably expect that all the objects can do such a thing. So we declare an interface: interface ObjectIveDeserialized { void doTheThingIWantThemToDo(); } Then, presuming that you will know all of the formats they can be in at compile-time (you must, else how could you write a parser for them?) then you just declare another interface: interface FileParser { ObjectIveDeserialized tryToDeserializeThisAndReturnNullIfIFail(Stream input); } Then you just have a list of all FileParsers and try each of them until one works. Maybe I'm completely misunderstanding you, but this doesn't seem to bad in D. How would you do it in a dynamic language like Python, Smalltalk, Ruby? Cheers, Reiner
Aug 31 2006
parent Charles D Hixson <charleshixsn earthlink.net> writes:
Reiner Pope wrote:
 Charles D Hixson wrote:
 David Medlock wrote:
 Charles D Hixson wrote:
 xs0 wrote:

 ...




you are deserializing objects, but you don't know what type they are. After you have deserialized them, you presumably want to do something with them. Am I right? So, presuming you want to do something with them, you can probably expect that all the objects can do such a thing. So we declare an interface: interface ObjectIveDeserialized { void doTheThingIWantThemToDo(); } Then, presuming that you will know all of the formats they can be in at compile-time (you must, else how could you write a parser for them?) then you just declare another interface: interface FileParser { ObjectIveDeserialized tryToDeserializeThisAndReturnNullIfIFail(Stream input); } Then you just have a list of all FileParsers and try each of them until one works. Maybe I'm completely misunderstanding you, but this doesn't seem to bad in D. How would you do it in a dynamic language like Python, Smalltalk, Ruby? Cheers, Reiner

what you want. You can EXPECT* that they'll be able to...but you won't be able to know. E.g. "In English you can verb any noun in the languge." works, but it's not true. You can only very ALMOST any noun in the language. So you've got to be able to check. And it's got to be a run-time check. More basically, I can't know ahead of time the class of the object that I'll be deserializing. I can have an expectation, but even that expectation is a run-time kind of thing. (Files have been known to get desynchronized, so I've got to be able to detect that what I got wasn't what I expected to get, and recover gracefully.) As for just HOW I'll use it...I haven't written that part yet, It involves requiring that each class implement two methods: __getstate__ and __setstate__ to specify how it should be saved and restored. Once it's restored, the language maintains a dict (think associated array) containing all the methods that it implements, so it's easy to check which of several alternatives can be used...if any. In D even the deserialization would require 20-50 times as much code per class. Similarly for the original serialization...because the Python language has included in it's library classes Pickle and bsddb. (As a first step I'm going to implement a Persistent class. I have the model of the shelve class to help me over any tricky spots, even though I intend to use a different database and a different basic approach. And, if I somehow couldn't, I could use the shelve class itself as a fallback Persistent class...though that would necessitate a redesign of the structure that I've been putting together. (Design first, code next...reiterate until done. If you don't design first, you won't know where you're going. If you don't code once you've got a chunk of the design complete, you won't know that your design is workable. So you've got to iterate.) * expecting that something is true means that you know it's usually true, but you also know that it sometimes isn't. If you can't computer even an approximate mean value, then you can't expect. If you can derive a standard deviation of zero, then you don't need to settle for expecting.
Sep 01 2006
prev sibling parent reply Paolo Invernizzi <arathorn NOSPAM_fastwebnet.it> writes:
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

Aug 31 2006
parent reply xs0 <xs0 xs0.com> writes:
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
Aug 31 2006
parent Paolo Invernizzi <arathorn NOSPAM_fastwebnet.it> writes:
xs0 wrote:

 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.

That's true...
 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).

That's true again... auto a = new SomeInterface is meaningless, as you cannot tell what 'concrete' class you need. My fault. --- Paolo
Aug 31 2006