As a component author, one thing you can do with a parameter that you can't do with an IN pin is "correct" an out-of-bounds value to the closest permissible value.
For instance, take the 'pwmgen' component. The 'pwm-freq' parameter has an upper limit related to its period (up to the frequency defined by 2 periods), and if 'dither-pwm' is false than it can only taken on certain discrete values equal to whole multiples of the period. If 'pwm-freq' is a parameter, then the user can set it and then query the actual value. But if it is an IN pin then this can't be done, as a component isn't allowed to assign a value to its own IN pin. So what do you do--have a new OUT parameter 'pwm-freq-actual' for each IN pin of this kind? You can't change the pin to an IO pin, because you can't link an OUT pin and an IO pin on the same net. Almost certainly the intended 'driver' of the value is going to more naturally be OUT than IO; I don't like the idea of a proliferation of IO pins just to satisfy this use case. Jeff ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
