Gord, I really would like to understand what user requirements are driving this complexity. Until we all understand why such constructs are needed in a concrete form, comparison in the abstract will be meaningless. I can give you my best guess as to how this might work, but you do realize that we are now treading in the dangerous area of design-by-committee. Neither one of us (surely not me) has a working prototype nor anything that even remotely resembles actual user experience with these types of constructs. So devoid of any requirements, here is my best guess as to how these constructs should behave: 1) is there any correspondence to our "schedulefree" class? There are two class forms that fit the description. A class that is truly pure, that is, it contains no (blocking) tasks, and no side effects outside the class. Such a class is truly schedule free and should exhibit no restrictions. The second class, is the proposed parameterized class, that is, a class that has no pre-defined scheduling behavior. The scheduling of such parameterized classes is determined by their instantiation (in the same manner as any other parameterized class). Once the class scheduling has been determined it can no longer be changed. 2) under what conditions (if any) is one required to use the parametric form? When (if ever) would it be an error? The parametric form is useful for declaring a class with blocking semantics once, and used in multiple contexts. Each such parameterized class would exhibit different scheduling behavior and would be subject to a different set of semantic restrictions. It would be an error to attempt to change via the parameter the behavior of a class whose scheduling semantics have already been fixed. 3) what restrictions (if any) exist in terms of extension prior to and/or after defining the parametric binding? Some simple rules (similar to the three we proposed) would be useful. It should permissible to use the parametric extension of any "schedulefree" class (as defined in item 1). The context binding can be left up to the next extension or fixed at any particular extension. Once fixed, the context cannot be changed. If this process results in a class with potentially mixed scheduling semantics, it shall be an error. 4) What is the relationship between predefined class types such as mailbox (C.2) and a context parametric class? No relationship. A mailbox is a built-in class that exhibits some properties that user-defined classes cannot easily replicate: 1) The built-in class can be instantiated with no specific type. 2) A mailbox instantiated with no type parameter has the ability to perform run-time type checking The mailbox class can be used freely in either a program or a module/interface context. BTW, the mailbox is no different than a user-defined class in a package (in the Active domain), but, as any other such classes, programs have access to them. 5) Are there any restrictions regarding containment relationships? How are those restrictions expressed? There are no containment restrictions, other than the existing visibility rules. 6) It seems that any reusable class would have to be defined in a parametric manner. No. Only classes that exhibit blocking behavior that need to be used in both an Active and a Reactive context would need to be parameterized in this manner. I believe there are very few classes (if any) that satisfy this criteria. Since, I believe, parametric types become instantiated types when passed through a type parameter, is there any mechanism for having something equivalent to a schedulefree class propagate through a module hierarchy? I don't understand why such a complex mechanism is useful or even desirable, but if this is necessary then users can stick with a pure class (as defined in point 1) or parameterize the class at the top of the hierarchy: Since programs do not have structural hierarchy, a hierarchy implies strictly a module hierarchy. However, I stress once again that I have no user model on which to base these decisions. Arturo ----- Original Message ----- From: "Gordon Vreugdenhil" <gordonv@Model.com> To: "SV_EC List" <sv-ec@eda.org> Sent: Wednesday, April 27, 2005 9:55 AM Subject: [sv-ec] Questions on Arturo's class scheduling/extension approach Arturo, In terms of your basic idea for using parameterization in conjunction with classes, I would like to specifically list some of the questions that I raised during the face-to-face. I think that we need to have some direct comparison of the nature of the rules that result from our suggestion versus your suggestion and your desire to have stronger enforcement of program versus design. Specifically: 1) is there any correspondence to our "schedulefree" class? 2) under what conditions (if any) is one required to use the parametric form? When (if ever) would it be an error? 3) what restrictions (if any) exist in terms of extension prior to and/or after defining the parametric binding? Some simple rules (similar to the three we proposed) would be useful. 4) What is the relationship between predefined class types such as mailbox (C.2) and a context parametric class? 5) Are there any restrictions regarding containment relationships? How are those restrictions expressed? 6) It seems that any reusable class would have to be defined in a parametric manner. Since, I believe, parametric types become instantiated types when passed through a type parameter, is there any mechanism for having something equivalent to a schedulefree class propagate through a module hierarchy? Once we see more details we can get a better idea if this would be a feasible and clean approach. Gord -- -------------------------------------------------------------------- Gordon Vreugdenhil, Staff Engineer 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Wed Apr 27 19:21:14 2005
This archive was generated by hypermail 2.1.8 : Wed Apr 27 2005 - 19:21:46 PDT