This project is read-only.

There are some rules to keep in mind when writing instructions with DPL variables.

  1. If we define a DPL variable, it is assumed that it will contain at least one method, property, interface, member or class from the inspected code. A DPL variable is a set that cannot be empty: as soon as a DPL variable is empty, the pattern is considered as not existing on the inspected code base.
  2. We do not consider members belonging to methods or properties, because they are disposed after the call. The DPL analyzer, however, keeps track of the possible calls done by those members.
  3. We do not consider value types in the DPL variables. In the DPL philosophy, value types are just here to help controlling the execution flow; DPL is just interested in the execution flow tree that can be represented in a minimal manner without the value types.
  4. We do not consider class members that are never instantiated and will never be; The DPL analyzer ignores them.
  5. We consider that a method or property call is one transaction (that can go both ways from the caller to the sender), and that asynchronous method calls with callbacks are two distinct transactions. In DPL, when an element calls another, it is expected to do nothing else until he gets an answer; that’s not the case with asynchronous methods.

There are, also, some limitations in the DPL 1.0 implementations

  1. The DPL 1.0 analyzer ignores delegates (and therefore ignores Func and Action C# keywords)
  2. The DPL 1.0 analyzer ignores the Task library
  3. The DPL 1.0 analyzer does not yet deal with asynchronous calls
  4. The DPL 1.0 does not yet deal with generic types.



Last edited Jul 17, 2012 at 8:57 PM by kherty, version 1


No comments yet.