On 17/05/2011 12:19, Joerg Schuelke wrote:
Am Mon, 16 May 2011 15:35:24 +0100
schrieb Martin<f...@mfriebe.de>:
{$EXPAND ProcFoo(1)}
// the code in thr try finally block
{$EXPAND ProcFooEnd}
I can see that happen very easy?
And there we are, Pascal would be down to where C is now.
There is no answer for that, you know. But you can always decide not to
accept any code inside rtl, packages,tools, whatever which contains
macros. Easy. If it compiles with warning, back to sender.
1) The point is, one may not be able to reject it.
If I used a 3rd party package (open source) for a long time, heavily
relaying on it. And the add it, and I need a bug fix, that requires me
to update....
2) the example itself is beside the point.
All our examples are beside the point. Mine, yours, any
I think we can easily agree on the following:
1) It is possible to find examples that some people may want to use
(never mind if alternatives exist)
2) It is always possible to find examples of (lack of a better word):
"abuse"
As for 1, you made yourself a statement: It will be a few people only in
some rare cases. I can try to find your emails.
As for 2, it is mostly there problem, so why bother? Except for if such
code gets into the public domain, as described above
Any way, I feel neither of those 2 statements can be argued (with the
hope of success). I think that can be concluded, after about 85 mails,
trying to find the ultimate example for either side, and no-one any
closer to "proving their point"...
-----
Or at least they can not be argued, unless we answer this question:
Should the compiler protect people from doing potentially dangerous
thinks (knowing this is never a 100% protection anyway)
C obviously doesn't give a damm what people do to themself.
Pascal is supposed to care about it?
If that care is wanted, then the bad examples may gain some importance....
------
To me that leaves one other remaining questions. But feel free to add
other points...
Looking at it as a potential feature. How does one evaluate if a feature
should be added.
After all adding features has always been a selective process. this is
not new for this case....
1) Is there a need for this feature => We apparently have trouble to
agree on this point. There may be a need for some
2) Does the cost/benefit equation work out
We need to define "need (for feature)", "cost" and "benefit" (benefit is
somewhat coupled to need)
For you as an individual, there is a need, and the benefit is bigger
than the cost.
For me as individual, it is the opposite.
To get a fairer measure we can (in my opinion) only base this on average
values. If you take the entire community, and (in lack of better data
take a guess how many people need it, how many may use it, and how many
may be affected. And assume some averages based on this.
The definition of the terms below, are not solely meant for "macro
feature" => they apply to every feature (past/future/accepted/rejected)
- every feature shares the same risks, and provides benefits, and for
every feature this cost/benefit can be calculated
"need"
=> The amount of people that want this feature to be implemented (in
this case feature means the extension from what it currently already is)
=> It should not matter "why" they want it (because we tried that
discussionm without success), but only "if" they want it.
"cost"
=> side-effects of the feature
- This can be the above described undesired exposure to the use of the
feature by others (in the case that use of the code of the other can not
be avoided). Probably low risk.
- this can be any side effect it has on the compiler. (all those are
potential / the may or may not apply, the may pose a very small, or not
so small risk...)
Bugs intruduced (now or in future)
Resource usage, memory, cpu time (potential slow down)
Effects on future features / making it harder to add other features
(which may be wanted by a bigger amount of people, provide greater benefits
Maintenance cost of the code itself
"benefit"
- objective benefits: like the ability to write code that by some
definition is better/cleaner
- subjective benefits: the ability for some individuals,to use the
feature, for whatever perceived gain
As for the need/benefit => It is not known how many people would be
affected.
But you said yourself several times, probably only a few, and only in
few cases
As for cost, we do not know how many risks will actually turn into
reality (so maintenance cost for example will exist). But if any risk
happens to come true, it affects every one.
Based on this. The question is does the benefits really outweigh the cost ?
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
