digitalmars.D.learn - Interface problems
- Mandeep Singh Brar (12/12) Jan 25 2011 Hi,
- bearophile (6/11) Jan 25 2011 What kind of comparisons do you need to perform and why?
- Mandeep Singh Brar (28/37) Jan 25 2011 In the following snippet:
- Dmitry Olshansky (36/72) Jan 26 2011 You should use 'is' for such kind of thing. The problem is that == uses
- Steven Schveighoffer (10/32) Jan 26 2011 This is hardly a solution. He wants to do value comparison, not identit...
- Stanislav Blinov (27/34) Jan 27 2011 The recent discussion in D group about destructor order brought me to
- Mandeep Singh Brar (32/39) Jan 27 2011 The recent discussion in D group about destructor order brought me to
- Stanislav Blinov (3/45) Jan 27 2011 There is bugzilla: d.puremagic.com/issues. You can create enhancement
- Steven Schveighoffer (15/52) Jan 28 2011 It's because everywhere in the compiler, an interface is considered a
Hi, Not a question but just raising a concern i am facing again and again. The current implementation of interfaces seem to be creating a number of problems. I am not able to: - find indexOf interface in an interface range using std.algorithm. - compare interface objects - assign interface to generic objects. Does COM support warrant so much weight so as to break the interfaces implementation from D1 and all other languages. What is the way to get this addressed (is there a possibility at all). Thanks Mandeep
Jan 25 2011
Mandeep Singh Brar:I am not able to: - find indexOf interface in an interface range using std.algorithm.I don't understand. Please explain better.- compare interface objectsWhat kind of comparisons do you need to perform and why?- assign interface to generic objects.Why do you need to do this? Bye, bearophile
Jan 25 2011
Mandeep Singh Brar:I am not able to: - find indexOf interface in an interface range using std.algorithm.I don't understand. Please explain better.In the following snippet: Interface interfaceA{} class C:interfaceA{} class D:interfaceA{} interfaceA[] registry; register(interfaceA a) { registry ~= a; } unregister(interfaceA a) {idx = registry.indexOf(a); registry.replace(idx, idx+1, null); } In the above statement indexOf does not work.- compare interface objectsWhat kind of comparisons do you need to perform and why?Simple comparisons like in the below snippet class A { interfaceTest myInstance; setInstance(interfaceTest interfaceInstance) { if(myInstance != interfaceInstance) //does not work { updateMyInstance; doStuff; } } }- assign interface to generic objects.Why do you need to do this?Just store various types of objects in a generic way like Object[] objects; objects ~= objA; objects~= interB and so on. I cant use Variant because interface can not be assigned to Variants and i cant use Objects too.Bye, bearophileThanks Mandeep
Jan 25 2011
On 26.01.2011 8:12, Mandeep Singh Brar wrote:Mandeep Singh Brar:You should use 'is' for such kind of thing. The problem is that == uses opEquals or opCmp, there is no such thing for interfaces AFIKT. But for every pointer like type we can check if they are the same with 'is'. Here is your fixed snippet : import std.algorithm; import std.array; interface interfaceA{} class C:interfaceA{} class D:interfaceA{} interfaceA[] registry; void register(interfaceA a) { registry ~= a; } void unregister(interfaceA a) { auto idx = indexOf!"a is b"(registry,a); registry.replace(idx,idx+1, null); } void main(){ auto b = new D(); register(new C()); register(b); unregister(b); }I am not able to: - find indexOf interface in an interface range using std.algorithm. I don't understand. Please explain better.In the following snippet: Interface interfaceA{} class C:interfaceA{} class D:interfaceA{} interfaceA[] registry; register(interfaceA a) { registry ~= a; } unregister(interfaceA a) {idx = registry.indexOf(a); registry.replace(idx, idx+1, null); } In the above statement indexOf does not work.Yeah, here it sucks. 'is' is your best chance ;)- compare interface objectsHere just use '!is ' instead of != [snip]What kind of comparisons do you need to perform and why?Simple comparisons like in the below snippet class A { interfaceTest myInstance; setInstance(interfaceTest interfaceInstance) { if(myInstance != interfaceInstance) //does not work { updateMyInstance; doStuff; } } }Just store various types of objects in a generic way like Object[] objects; objects ~= objA; objects~= interB and so on. I cant use Variant because interface can not be assigned to Variants and i cant use Objects too.If you need to pile up different interfaces (no occasional Object ). The workaround would be to inherit all your interfaces from a common base like: interface Base{} interface A: Base{...} interface B: Base{...} class CA: A{.. } Base[] pile; pile ~= new CA();-- Dmitry OlshanskyBye, bearophileThanks Mandeep
Jan 26 2011
On Wed, 26 Jan 2011 05:12:39 -0500, Dmitry Olshansky <dmitry.olsh gmail.com> wrote:On 26.01.2011 8:12, Mandeep Singh Brar wrote:This is hardly a solution. He wants to do value comparison, not identity comparison. The real fix is to make interface assume it is an Object, so it can be implicitly cast to Object, and find another way to implement COM interfaces. The COM interface "hack" is way outdated and extremely harmful, esp. on OS' who *don't use COM*! I can't see how the benefits it has outweigh the problems it causes. -SteveMandeep Singh Brar:You should use 'is' for such kind of thing. The problem is that == uses opEquals or opCmp, there is no such thing for interfaces AFIKT. But for every pointer like type we can check if they are the same with 'is'.I am not able to: - find indexOf interface in an interface range using std.algorithm. I don't understand. Please explain better.In the following snippet: Interface interfaceA{} class C:interfaceA{} class D:interfaceA{} interfaceA[] registry; register(interfaceA a) { registry ~= a; } unregister(interfaceA a) {idx = registry.indexOf(a); registry.replace(idx, idx+1, null); } In the above statement indexOf does not work.
Jan 26 2011
26.01.2011 16:54, Steven Schveighoffer пишет:This is hardly a solution. He wants to do value comparison, not identity comparison. The real fix is to make interface assume it is an Object, so it can be implicitly cast to Object, and find another way to implement COM interfaces. The COM interface "hack" is way outdated and extremely harmful, esp. on OS' who *don't use COM*! I can't see how the benefits it has outweigh the problems it causes.The recent discussion in D group about destructor order brought me to yet another question about interfaces. Currently, functions that should accept classes as parameters, e.g. clear(), accept interfaces as well: void clear(T)(T obj) if (is(T == class)) // note the constraint { /*...*/ } interface I {} class A : I {} void main() { I a = new A; // note that typeof(a) is I, not A clear(a); } This compiles. But raises a question: how come? If it is assumed that a reference to interface is not necessarily a D class instance, then it shouldn't. The fact that it compiles even more ambiguates the purpose and usage of interfaces. I agree with Steven. Having a support for COM, CORBA and so on in the language is great, but wouldn't it be better to specify it explicitly? Maybe solidify the usage of 'extern' keyword? interface D {} // instances are guaranteed to be D Objects extern interface E {} // instances may or may not be D Objects (COM and alike) I mean, it's already there in the language and is described in 'Interfacing to C++' in the documentation. Though currently, extern interfaces are accepted by is(T == class) constraint as well.
Jan 27 2011
26.01.2011 16:54, Steven Schveighoffer пишет:This is hardly a solution. He wants to do value comparison, not identity comparison. The real fix is to make interface assume it is an Object, so it can be implicitly cast to Object, and find another way to implement COM interfaces. The COM interface "hack" is way outdated and extremely harmful, esp. on OS' who *don't use COM*! I can't see how the benefits it has outweigh the problems it causes.The recent discussion in D group about destructor order brought me to yet another question about interfaces. Currently, functions that should accept classes as parameters, e.g. clear(), accept interfaces as well: void clear(T)(T obj) if (is(T == class)) // note the constraint { /*...*/ } interface I {} class A : I {} void main() { I a = new A; // note that typeof(a) is I, not A clear(a); } This compiles. But raises a question: how come? If it is assumed that a reference to interface is not necessarily a D class instance, then it shouldn't. The fact that it compiles even more ambiguates the purpose and usage of interfaces. I agree with Steven. Having a support for COM, CORBA and so on in the language is great, but wouldn't it be better to specify it explicitly? Maybe solidify the usage of 'extern' keyword? interface D {} // instances are guaranteed to be D Objects extern interface E {} // instances may or may not be D Objects (COM and alike) I mean, it's already there in the language and is described in 'Interfacing to C++' in the documentation. Though currently, extern interfaces are accepted by is(T == class) constraint as well. Second this thought. Interface IMHO are far too basic for a functionality tweak. Would also like to understand the way to raise such requests and take them to their logical conclusion. Regards Mandeep
Jan 27 2011
Stanislav Blinov <stanislav.blinov gmail.com> On 01/27/2011 09:27 PM, Mandeep Singh Brar wrote:26.01.2011 16:54, Steven Schveighoffer пишет:There is bugzilla: d.puremagic.com/issues. You can create enhancement requests there along with bugreports.This is hardly a solution. He wants to do value comparison, not identity comparison. The real fix is to make interface assume it is an Object, so it can be implicitly cast to Object, and find another way to implement COM interfaces. The COM interface "hack" is way outdated and extremely harmful, esp. on OS' who *don't use COM*! I can't see how the benefits it has outweigh the problems it causes.The recent discussion in D group about destructor order brought me to yet another question about interfaces. Currently, functions that should accept classes as parameters, e.g. clear(), accept interfaces as well: void clear(T)(T obj) if (is(T == class)) // note the constraint { /*...*/ } interface I {} class A : I {} void main() { I a = new A; // note that typeof(a) is I, not A clear(a); } This compiles. But raises a question: how come? If it is assumed that a reference to interface is not necessarily a D class instance, then it shouldn't. The fact that it compiles even more ambiguates the purpose and usage of interfaces. I agree with Steven. Having a support for COM, CORBA and so on in the language is great, but wouldn't it be better to specify it explicitly? Maybe solidify the usage of 'extern' keyword? interface D {} // instances are guaranteed to be D Objects extern interface E {} // instances may or may not be D Objects (COM and alike) I mean, it's already there in the language and is described in 'Interfacing to C++' in the documentation. Though currently, extern interfaces are accepted by is(T == class) constraint as well. Second this thought. Interface IMHO are far too basic for a functionality tweak. Would also like to understand the way to raise such requests and take them to their logical conclusion. Regards Mandeep
Jan 27 2011
On Thu, 27 Jan 2011 09:26:28 -0500, Stanislav Blinov <blinov loniir.ru> wrote:26.01.2011 16:54, Steven Schveighoffer пишет:It's because everywhere in the compiler, an interface is considered a class (I think even the type representing an interface is derived from the type representing class). Except one, and that's implicit casting to Object. My thought is, we already have extern(C++) interface, why not extern(COM) interface? But we could even leave the notion of interfaces deriving from IUnknown as COM interfaces and just have the compiler check if an interface derives from IUnknown. In fact, it *ALREADY DOES THIS* because it has to treat the layout of an IUnknown interface differently from another interface. The whole argument to have interfaces not derive from Object because of COM is standing on such poor footing that I can't see how it's taken this long to fix. -SteveThis is hardly a solution. He wants to do value comparison, not identity comparison. The real fix is to make interface assume it is an Object, so it can be implicitly cast to Object, and find another way to implement COM interfaces. The COM interface "hack" is way outdated and extremely harmful, esp. on OS' who *don't use COM*! I can't see how the benefits it has outweigh the problems it causes.The recent discussion in D group about destructor order brought me to yet another question about interfaces. Currently, functions that should accept classes as parameters, e.g. clear(), accept interfaces as well: void clear(T)(T obj) if (is(T == class)) // note the constraint { /*...*/ } interface I {} class A : I {} void main() { I a = new A; // note that typeof(a) is I, not A clear(a); } This compiles. But raises a question: how come? If it is assumed that a reference to interface is not necessarily a D class instance, then it shouldn't. The fact that it compiles even more ambiguates the purpose and usage of interfaces. I agree with Steven. Having a support for COM, CORBA and so on in the language is great, but wouldn't it be better to specify it explicitly? Maybe solidify the usage of 'extern' keyword? interface D {} // instances are guaranteed to be D Objects extern interface E {} // instances may or may not be D Objects (COM and alike) I mean, it's already there in the language and is described in 'Interfacing to C++' in the documentation. Though currently, extern interfaces are accepted by is(T == class) constraint as well.
Jan 28 2011