[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf issue #1: language versioning
Good Afternoon, Bob,
Suppose that a feature is deprecated on a version change.
If your script depends on that feature
. If you check for PolicyScriptVersion1, you stop your
. If you did not check for PolicyScriptVersion1, then your
script would fail to execute, incrementing
If your script did not depend on that feature
. If you check for PolicyScriptVersion1, you stop
the script unnecessarily. There is no way to check
whether the feature change would have affected your
script, since there is no way to know ahead of time
what the feature change might be.
. If you don't check, your script executes as before.
If a feature is deprecated in a future version of the language,
and you wanted to use that feature (say as a transition mechanism)
then checking for presence/lack of version 1 support may be useful.
However, without knowing a priori what features might be deprecated,
one is unlikely to write version checking code with those features
Taking another perspective, say I have a bunch of scripts that I
have written for version 1 of the script language. Version 2 comes
out. Do I want to modify every script I use, or just the
scripts that depend on a version 1 feature?
I would prefer to modify only the scripts that would fail because
they depend on a deprecated feature.
This is assuming that no feature's functionality changes without
that feature being deprecated. This also assumes that we ever
I welcome a counter-example. I have this feeling that I am missing
On Friday, April 6 2001, "Robert Moore" <firstname.lastname@example.org> wrote:
> I don't see how your second scenario helps. If I write
> a script today and don't start it with a test for the
> capability PolicyScriptVersion1, then presumably I'm
> also not going to start it with a test for the absence
> of the capability (incapability?) noPolicyScriptVersion1.
> So adding this incapability later doesn't help me.
> In fact, I'm worse off than before. You're trading a check
> for the presence of a capatility PolicyScriptVersion1 that
> would be defined now, for a test for the absence of an
> incapability noPolicyScriptVersion1 that might be defined
> Bob Moore
> Advanced Design and Technology
> Application Integration Middleware Division
> IBM Software Group
> Steve Moulton <email@example.com>@snmp.com on 04/05/2001 02:13:44 PM
> I see two scenarios.
> . We are able to maintain backward compability across the language
> releases. Like Steve, I agree that this ideal, and likely.
> . We mess something up. In this case, when we revise the language,
> we add two capabilities: policyScriptVersion2, and,
> noPolicyScriptVersion1, which would indicate that some "features"
> of version 1 have been deprecated.