• TechnoZeus (39/39) Apr 20 2005 Perhaps this is already implemented.
• Mike Parker (7/10) Apr 21 2005 In my mind, this just sounds too complicated to maintain for very little...
• TechnoZeus (11/21) Apr 21 2005 Okay... thanks.

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

Perhaps this is already implemented.
Since I'm not working with any "old code" I haven't even looked...
but nonetheless, I thought it was worth mentioning,
just in case.

As I understand it from the documentation, deprication is an all or nothing
situation as it stands.
By this, I mean that one can swith the allowance of pedricated features on or
off, but nowhere in-between.

I would like to propose that the concept of deprication levels be entertained.
A lower level would be less important to phase out,
and a higher level would be more important to phase out.

When a feature is initially depricated, it would be given a low deprication
level such as 1,
or perhaps 2 or 3 if it's something that everyone agrees needs to go.

As more features are depricated and older depricated features are phased out,
occasionally,
all depricated features would increase in level by 1,
or perhaps just those that are known to be reletively well phased out.

This would allow asynchronous phasing out of depricated features,
while giving the software developer more control as well as some built-in
guidance,
when it comes to choosing what needs phased out next.

For example, while the "-d" compiler switch allows all depricated features,
perhaps "-d3" could allow only those depricated features with a level of 3 or
lower,
allowing newly depricated features to be put on a back burner, so to speak,
while "-d300" would only disallow features with a deprication level above 300,
allowing them to concentrate on phasing out the most extreme cases first,
before reducing down to something like "-d250" and starting on the next batch.

This would be of absolutely no use to me personally, at this time,
but in the discussion about adding ":=" as a value assignment operator,
when I mentioned the possibility of depricating the use of "=" in cases where
it also
functions as a value assignment operator,
and it occurred to me that some day I may have code that needs something like
that phased out.
That made me think about what it must be like to have several things needing to
be phased out at once,
such as is likely the case for people using a lot of "C-like" code,
possibly adapted from older C code that they wanted to migrate into the D
language.

I would guess that in such cases, the ability to allow "some" deprecated
features would be handy.

One further note:

I would suggest avoiding having gaps in the deprecation levels.
For example, if there is only one feature with a deprecation level of exactly
97,
and that feature is phased out while there are still other features with higher
deprecation levels,
then those with higher deprecation levels should have their level reduced
accordingly,
to close the gap.

TZ

Mike Parker <aldacron71 yahoo.com> writes:

TechnoZeus wrote:

 
 As I understand it from the documentation, deprication is an all or nothing
situation as it stands.
 By this, I mean that one can swith the allowance of pedricated features on or
off, but nowhere in-between.

In my mind, this just sounds too complicated to maintain for very little 
benefit. The set of deprecated features at any given time is generally 
small, and the compiler lets you know when you are using any deprecated 
features. So, telling it to allow specific features and disallow others 
makes no sense, when you can actively choose to use some and not use 
others. If you use any by mistake, the compiler tells you and you remove it.

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

"Mike Parker" <aldacron71 yahoo.com> wrote in message
news:d47sgr$2m09$1 digitaldaemon.com...
 TechnoZeus wrote:

 As I understand it from the documentation, deprication is an all or nothing
situation as it stands.
 By this, I mean that one can swith the allowance of pedricated features on or
off, but nowhere in-between.

 In my mind, this just sounds too complicated to maintain for very little
 benefit. The set of deprecated features at any given time is generally
 small, and the compiler lets you know when you are using any deprecated
 features. So, telling it to allow specific features and disallow others
 makes no sense, when you can actively choose to use some and not use
 others. If you use any by mistake, the compiler tells you and you remove it.

Okay... thanks.
Like I said... no experience with it.
Just thought I would pass along my thoughts on the subject anyway.

I thought D had a lot of old C features in it,
just from things I've heard people say,
and D code examples that I've seen so far.

Still seems to me that it would be better,
but if there are very few depricated features,
then you're probably right about it being more effort to maintain than it's
worth.

TZ