Subject | Legacy Behavior |
---|---|
Author | Jim Starkey |
Post date | 2004-12-22T15:48:02Z |
Dmitry Yemanov wrote:
worth discussing, which is what legacy behaviors should be preserved?
Programs that use advertised features for the purpose documented should
be respected at almost all costs. If we make a mistake in language or
API design, we should live with it, both out of respect for our users
and as a reminder to think more and better next time. At the other end
of the spectrum are people who take advantage of implementation
artifacts, for example, the nature of handles. I don't have the
slightest qualm about yanking the rug out from underneath these guys.
Any system are arbitrary artifact and every system has to evolve.
Freezing everything freezes progress. If somebody builds in a
dependency on an artifact due to bad taste, bad planning, a lack of
knowledge, bad toilet training, or whatever, that's too bad. His
application will break over an upgrade and hopefully he'll learn
something from it.
I prefer not to give people rope to hang themselves. Unfortunately, the
Borland guys didn't have this philosophy. The two types of procedures
should not have been comingled. Somebody had the beastly clever idea
that a single syntax and implementation could painlessly server two
masters. Cute. But now we have the pain.
It is certainly possible to write a procedure that does something
meaningful if invoked in either environment, though it is unlikely that
anyone has actually done this. The fact that the procedure can't tell
which way it was invoked is kind of a showstopper. But if someone did,
he either knew or should have known that this was entirely too cute to
work in the long run. And if not, next time he'll know.
Simply put, we should not let the possible existence of a utter dolt
impede progress.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>"Geoff Worboys" <geoff@...> wrote:I don't particularly care about this case, but it raises a question
>
>
>>Personnally I would also like an exception to be thrown when
>>a procedure is called with an incompatible method. This way,
>>as a developer, I get told when I've stuffed up. Possibly
>>this is undesireable for backwards compatibility reasons.
>>
>>
>
>Now we have:
>
>CREATE PROCEDURE P RETURNS (X INT)
>BEGIN
> X = 0;
> SUSPEND;
>END
>
>And by design it has two compatible execution methods. And we must preserve
>it, not because it's a legacy stuff, but because it's a useful feature,
>IMHO.
>
>
>
>
worth discussing, which is what legacy behaviors should be preserved?
Programs that use advertised features for the purpose documented should
be respected at almost all costs. If we make a mistake in language or
API design, we should live with it, both out of respect for our users
and as a reminder to think more and better next time. At the other end
of the spectrum are people who take advantage of implementation
artifacts, for example, the nature of handles. I don't have the
slightest qualm about yanking the rug out from underneath these guys.
Any system are arbitrary artifact and every system has to evolve.
Freezing everything freezes progress. If somebody builds in a
dependency on an artifact due to bad taste, bad planning, a lack of
knowledge, bad toilet training, or whatever, that's too bad. His
application will break over an upgrade and hopefully he'll learn
something from it.
I prefer not to give people rope to hang themselves. Unfortunately, the
Borland guys didn't have this philosophy. The two types of procedures
should not have been comingled. Somebody had the beastly clever idea
that a single syntax and implementation could painlessly server two
masters. Cute. But now we have the pain.
It is certainly possible to write a procedure that does something
meaningful if invoked in either environment, though it is unlikely that
anyone has actually done this. The fact that the procedure can't tell
which way it was invoked is kind of a showstopper. But if someone did,
he either knew or should have known that this was entirely too cute to
work in the long run. And if not, next time he'll know.
Simply put, we should not let the possible existence of a utter dolt
impede progress.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376