A dual interface in COM is one that is able to be accessed via a DispInterface or via VTable methods.
Now can someone tell me what is exactly what the difference is between the two methods?
I thought that a VTable is a virtual table which holds the pointers to the different functions when implementing a class hierarchy which has virtual functions that can be overridden in child classes. However I do not see how this is related to a dual interface in COM?
In short, COM is binary specification, not a language specification. There really isn't a correlation between dual interfaces and deriving classes in code. Apples and oranges.
The VTable is "early bound" and this therefore faster. You know the type of method you are calling at compile time.
Using the DispInterface is "late bound" and is therefore slower, but more flexible. It's used extensively for scripting. The method and property types are determined at runtime.
I hope this brief explanation helps.
The main difference is in the way of calling object methods. In the case of DispInterface call goes through IDispatch::Invoke method (used in scripts or in the absence of the interface description) see remarks. This method is much slower second option. In the second case used directly VTable for method calls (used for calls from C + + or. NET languages)
I want only answer to additional Tony's questions.
If you want create a COM which can be accessible from VBScript/JScript or from old "classic" ASP you have to implement IDispatch.
In Visual Basic 6 or in VBA of MS Office one can use both ways. If you add Reference to your COM, then you will be use "early bound" (IUnknown or VTable). If you use your COM in VB6 or VBA with CreateObject ("ProgIdName"), that you will be use "late bound".
It is very important to understand, that to make COM accessible from VB6/VBA ect. it's not enough just implement IUnknown interface. You have to create and register Type Library with oleautomation attribute. To be able to do so, you can use in the interface of your COM only oleautomation compatible data types (see http://msdn.microsoft.com/en-us/library/aa367129%28VS.85%29.aspx). For understanding the type library play a role of client marshaling DLL, so it helps a client software like VB6/VBA to send correctly data as a parameters to your COM. You should don't forget, that even your COM will be an InProc server, a DLL, parameters will be not forwards directly to COM, but need be marshaled. During marshaling a copy of data will be created on the thread where run your COM. It makes your COM DLL thread safe from one side and you COM will be not crash if the thread calling your COM method will be ended before COM returns the value.
Probably my explanation about marshaling is not easy, but it's just important don't forget to create and register the Type Library which is better to save as a resource inside of COM.
Related
I want to do something like this:
module BusinessLogicVersion_1(clk, rst, d, q);
// Erudite business logic goes here
endmodule
module BusinessLogicVersion_2(clk, rst, d, q);
// Different implementation of same interface.
endmodule
// Then, when instantiating the module that requires an implementation of whatever interface,
// I want to do something like this:
ModuleXyz #(
.business_logic(BusinessLogicVersion_2) // <--- Pass an implementation of an interface as parameter
) (.clk(clk), .rst(rst), ...);
I have tried to find ways to do this, and from what I've read SV does not allow it.
My question is:
Is there a technical reason why this shouldn't be possible?
Technically, nothing is technically impossible in software given enough time, space and money! StackOverflow is not the forum for why kinds of questions.
SystemVerilog has a different approaches that implements what you are looking for. One way is called a configuration (See section 33. Configuring the contents of a design in the IEEE 1800-2017 SystemVerilog LRM).
For your case, what you would do is compile different versions of same module name ModuleXyz into different libraries and then use either command line options or a config block that selects which version to be selected for different instances. I would look at the LRM for examples.
The other method is using a _generate construct to select different modules you want instantiated. See section 27. Generate constructs. This is simpler, but less flexible since you have to know upfront which versions are available.
case(VERSION):
1: BusinessLogicVersion_1 inst (clk, rst, d, q);
2: BusinessLogicVersion_2 inst (clk, rst, d, q);
default: $error("Version does not exist");
endcase
I assume you're trying to do some kind of dependency injection, where the modules you're passing in are supposed to be different strategies. Also, I see from your profile that you're familiar with C++, so I'll try to map what you're trying to do onto that language. (Beware of gross simplifications or not-so-accurate analogies.)
A SystemVerilog module is akin to a C++ class. By passing a module name to you ModuleXyz, you're trying to do something like pass a class as a function argument in C++. This isn't possible in that language either. You generally pass instances of classes.
In order to pass an instance of a class, you'd need to first construct it. This would mean passing it your desired constructor arguments. Your module has ports, which are conceptually similar to a class's constructor arguments. When you instantiate a module, you connect its ports.
In your example, I'm guessing you would like to pass in the type of module that ModuleXyz should instantiate inside. In C++ you would generally pass a factory object, which knows how to construct the object you need, with the constructor arguments you want. This pattern isn't possible with modules, as only "direct" instantiation is allowed.
As #dave_59 pointed out, switching out module types is done using configurations. It's sort of like doing dynamic loading of different shared libraries, to switch out the implementations.
If your simulator doesn't support configurations (as language constructs), it will usually provide compile switches that allow you to implement something similar. It will compile different versions of the module, but you will be able to choose which one gets "linked".
If you really, really need to use dependency injection, I'd suggest you try to migrate your code from trying to pass modules, to passing interfaces. It is possible to pass instances of those around. Just remember, that you'll be passing already constructed instances, not types.
I am teaching myself how to use object oriented programming with MATLAB and have a question about access.
I have three current classes that need to interact with each other. One class, which I'll call main, is what the user will interface with (or the gui if I build one). Main stores all of the pertinent data that the use may want and has a few methods to perform some preprocessing and to construct the main object. Main also calls the constructors for the two other classes.
Another class, I'll call it instruction, loads information about the steps to process the data (this is a recursive process) and some other information.
The final class, which I'll call core, performs the core operations of the process.
Heres what my question is. Within main I have some "helper" methods that are used in the preprocessing. I want the access to these helper methods to be private so that the user cannot see or use them. Some of these helper functions also need to be used by the processes in core. My question is how do I grant access to the helper functions in main so that only main and core can access them? I have tried to understand the information provided here: http://www.mathworks.com/help/matlab/matlab_oop/selective-access-to-class-methods.html, but when I try something like:
classdef main < handle
%this is the main class
properties
core %the core object
instruction %the instruction object
end %properties
methods (Access = {?core,?main})
... %some code
end %methods
end %class
Matlab gives me this error:
Illegal value for attribute 'Access'.
Parameter must be a string.
Any help would be greatly appreciated!
Andrew
Btw, I realize that having three different classes is unnecessary here but as I stated I am just learning object oriented programming and when I started this project I thought it would be a good idea to have multiple classes because the total project will be over 5000 lines of code.
Is it possible you're using a relatively old version of MATLAB?
The ability to give access to class methods to specific classes was implemented in release 2012a.
If you're using a version of MATLAB older than that, you can only set method access attributes to public, protected or private.
Note that the documentation page you link to always refers to the current version of MATLAB (2014a at the moment). You can access old versions of the documentation via the website as well by logging into your MathWorks account.
If you have methods of main that need to be accessed by core, that could be a sign that you've designed your class relationships poorly. If core is a property of main, then perhaps it could be a method of core, and main could call it via core.
Selective access is needed quite rarely. The main reason for not using it, is that it breaks the encapsulation principle of OOP. I would consider changing your design, before implementing it.
For more information, check out the friend keyword in C++. Most likely you will find a lot of information on it, and why not to use it.
In this video from Google IO 2009, the presenter very quickly says that signatures of methods should return concrete types instead of interfaces.
From what I heard in the video, this has something to do with the GWT Java-to-Javascript compiler.
What's the reason behind this choice ?
What does the interface in the method signature do to the compiler ?
What methods can return interfaces instead of concrete types, and which are better off returning concrete instances ?
This has to do with the gwt-compiler, as you say correctly. EDIT: However, as Daniel noted in a comment below, this does not apply to the gwt-compiler in general but only when using GWT-RPC.
If you declare List instead of ArrayList as the return type, the gwt-compiler will include the complete List-hierarchy (i.e. all types implementing List) in your compiled code. If you use ArrayList, the compiler will only need to include the ArrayList hierarchy (i.e. all types implementing ArrayList -- which usually is just ArrayList itself). Using an interface instead of a concrete class you will pay a penalty in terms of compile time and in the size of your generated code (and thus the amount of code each user has to download when running your app).
You were also asking for the reason: If you use the interface (instead of a concrete class) the compiler does not know at compile time which implementations of these interfaces are going to be used. Thus, it includes all possible implementations.
Regarding your last question: all methods CAN be declared to return interface (that is what you ment, right?). However, the above penalty applies.
And by the way: As I understand it, this problem is not restricted to methods. It applies to all type declarations: variables, parameters. Whenever you use an interface to declare something, the compiler will include the complete hierarchy of sub-interfaces and implementing classes. (So obviously if you declare your own interface with only one or two implementing classes then you are not incurring a big penalty. That is how I use interfaces in GWT.)
In short: use concrete classes whenever possible.
(Small suggestion: it would help if you gave the time stamp when you refer to a video.)
This and other performance tips were presented at Google IO 2011 - High-performance GWT.
At about the 7 min point the speak addresses 'RPC Type Explosion':
For some reason I thought the GWT compiler would optimize it away again but it appears I was mistaken.
Before I start using CORBA I want to know something.
It would seem intuitive to me that you could use an IDL type as an attribute of another, which would then expose that attribute's methods to the client application (using ".") as well.
But is this possible?
For example (excuse my bad IDL):
interface Car{
attribute BrakePedal brakePedal;
//...
}
//then.. (place above)
interface BrakePedal{
void press();
//...
}
//...
Then in the client app, you could do: myCar.brakePedal.press();
CORBA would seem crappy if you couldn't do these kind of multi-level
object interfaces. After all, real-world objects are multi-level, right? So can
someone put my mind at ease and confirm (or try, if you already have CORBA set up) if this definitely works? None of the IDL documentation explicitly shows this in example, which is why I'm concerned. Thanks!
Declaring an attribute is logically equivalent to declaring a pair of accessor functions, one to read the value of the attribute, and one to write it (you can also have readonly attributes, in which case you would only get the read function).
It does appear from the CORBA spec. that you could put an interface name as an attribute name. I tried feeding such IDL to omniORB's IDL to C++ translator, and it didn't reject it. So I think it is allowed.
But, I'm really not sure you would want to do this in practice. Most CORBA experts recommend that if you are going to use attributes you only use readonly attributes. And for something like this, I would just declare my own function that returned an interface.
Note that you can't really do the syntax you want in the C++ mapping anyway; e.g.
server->brakePedal()->press(); // major resource leak here
brakePedal() is the attribute accessor function that returns a CORBA object reference. If you immediately call press() on it, you are going to leak the object reference.
To do this without a leak you would have to do something like this:
BrakePedal_var brakePedal(server->brakePedal());
brakePedal->press();
You simply can't obtain the notational convenience you want from attributes in this scenario with the C++ mapping (perhaps you could in the Python mapping). Because of this, and my general dislike for attributes, I'd just use a regular function to return the BrakePedal interface.
You don't understand something important about distributed objects: remote objects (whether implemented with CORBA, RMI, .NET remoting or web services) are not the same as local objects. Calls to CORBA objects are expensive, slow, and may fail due to network problems. The object.attribute.method() syntax would make it hard to see that two different remote calls are being executed on that one line, and make it hard to handle any failures that might occur.
I see the word thrown around often, and I may have used it myself in code and libraries over time, but I never really got it. In most write-ups I came across, they just went on expecting you to figure it out.
What is a Class Factory? Can someone explain the concept?
Here's some supplemental information that may help better understand several of the other shorter, although technically correct, answers.
In the strictest sense a Class Factory is a function or method that creates or selects a class and returns it, based on some condition determined from input parameters or global context. This is required when the type of object needed can't be determined until runtime. Implementation can be done directly when classes are themselves objects in the language being used, such as Python.
Since the primary use of any class is to create instances of itself, in languages such as C++ where classes are not objects that can be passed around and manipulated, a similar result can often be achieved by simulating "virtual constructors", where you call a base-class constructor but get back an instance of some derived class. This must be simulated because constructors can't really be virtual✶ in C++, which is why such object—not class—factories are usually implemented as standalone functions or static methods.
Although using object-factories is a simple and straight-forward scheme, they require the manual maintenance of a list of all supported types in the base class' make_object() function, which can be error-prone and labor-intensive (if not over-looked). It also violates encapsulation✶✶ since a member of base class must know about all of the base's concrete descendant classes (now and in the future).
✶ Virtual functions are normally resolved "late" by the actual type of object referenced, but in the case of constructors, the object doesn't exist yet, so the type must be determined by some other means.
✶✶ Encapsulation is a property of the design of a set of classes and functions where the knowledge of the implementation details of a particular class or function are hidden within it—and is one of the hallmarks of object-oriented programming.
Therefore the best/ideal implementations are those that can handle new candidate classes automatically when they're added, rather than having only a certain finite set currently hardcoded into the factory (although the trade-off is often deemed acceptable since the factory is the only place requiring modification).
James Coplien's 1991 book Advanced C++: Programming Styles and Idioms has details on one way to implement such virtual generic constructors in C++. There are even better ways to do this using C++ templates, but that's not covered in the book which predates their addition to the standard language definition. In fact, C++ templates are themselves class factories since they instantiate a new class whenever they're invoked with different actual type arguments.
Update: I located a 1998 paper Coplien wrote for EuroPLoP titled C++ Idioms where, among other things, he revises and regroups the idioms in his book into design-pattern form à la the 1994 Design Patterns: Elements of Re-Usable Object-Oriented Software book. Note especially the Virtual Constructor section (which uses his Envelope/Letter pattern structure).
Also see the related answers here to the question Class factory in Python as well as the 2001 Dr. Dobb's article about implementing them with C++ Templates titled Abstract Factory, Template Style.
A class factory constructs instances of other classes. Typically, the classes they create share a common base class or interface, but derived classes are returned.
For example, you could have a class factory that took a database connection string and returned a class implementing IDbConnection such as SqlConnection (class and interface from .Net)
A class factory is a method which (according to some parameters for example) returns you a customised class (not instantiated!).
The Wikipedia article gives a pretty good definition: http://en.wikipedia.org/wiki/Factory_pattern
But probably the most authoritative definition would be found in the Design Patterns book by Gamma et al. (commonly called the Gang of Four Book).
I felt that this explains it pretty well (for me, anyway). Class factories are used in the factory design pattern, I think.
Like other creational patterns, it [the factory design pattern]
deals with the problem of creating
objects (products) without specifying
the exact class of object that will be
created. The factory method design
pattern handles this problem by
defining a separate method for
creating the objects, which subclasses
can then override to specify the
derived type of product that will be
created. More generally, the term
factory method is often used to refer
to any method whose main purpose is
creation of objects.
http://en.wikipedia.org/wiki/Factory_method_pattern
Apologies if you've already read this and found it to be insufficient.