• Matthew (18/18) Feb 03 2004 Previously, I've tried to use the deprecation facility to change method ...
• Georg Wrede (2/3) Feb 04 2004 Could you be more specific?
• Matthew (12/16) Feb 04 2004 to
• Brad Anderson (1/4) Feb 04 2004 You can hit 6's on other issues. (And this from an American)
• Walter (7/10) Jun 03 2004 name
• Matthew (3/14) Jun 03 2004 Doh!

"Matthew" <matthew.hat stlsoft.dot.org> writes:

Previously, I've tried to use the deprecation facility to change method name
cases to fall in with the D style.

I recall that there were linker problems.

I want to change the method names of std.recls and std.windows.registry to
conform to the D style (even though it sucks like a Wurther's Original!) to
be a good citizen, but I'd like to keep the old methods, marked deprecate,
for a couple of versions. There are two reasons for this:

1. The instalment of my CUJ "Positive Integration" column in which the D and
Java mapping of recls are described is about to come out. The casing style
described in the article is the current (superior <g>) one. I'm not going to
screw my readers, and potentially put a lot of people off D, by changing
std.recls now, as people coming to it from the CUJ article will just think
it's an unstable load of old crap.

2. I think in general a robust and sane evolution of code should be
supported by the deprecation facilities - which are a bloody good idea! -
and case-changes should work just as well as any other ones.

BigW, please advise whether this question is surmountable.

Matthew

Georg Wrede <Georg_member pathlink.com> writes:

In article <bvp9uf$1hgm$1 digitaldaemon.com>, Matthew says...
conform to the D style (even though it sucks like a Wurther's Original!) to

Could you be more specific?

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Georg Wrede" <Georg_member pathlink.com> wrote in message
news:bvrino$2as9$1 digitaldaemon.com...
 In article <bvp9uf$1hgm$1 digitaldaemon.com>, Matthew says...
conform to the D style (even though it sucks like a Wurther's Original!)


to
 Could you be more specific?

Do you mean about what I personally think sucks about the D method naming
style? Simple, I don't like thisMethodNameStyle(), I prefer
ThisMethodNameSyle().

But I know I'm on a losing wicket, and I resolved a while back not to bother
swimming against this particular stream, hence my gripe being a
parenthetical aside.

Please, no-one waste time trying to persuade me, since I accept that's what
we're doing anyway.

What I am interested for all to consider is the main issue of my post.

Brad Anderson <brad sankaty.dot.com> writes:

 But I know I'm on a losing wicket, and I resolved a while back not to bother
 swimming against this particular stream, hence my gripe being a
 parenthetical aside.

You can hit 6's on other issues.  (And this from an American)

"Walter" <newshound digitalmars.com> writes:

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bvp9uf$1hgm$1 digitaldaemon.com...
 Previously, I've tried to use the deprecation facility to change method

name
 cases to fall in with the D style.

 I recall that there were linker problems.

That's most likely because what you did was have two names that only
differed by case. The linker, by default, ignores case and so will produce a
multiply defined symbol error. The solution is to link with /noi
(noignorecase).

"Matthew" <matthew.hat stlsoft.dot.org> writes:

Doh!

"Walter" <newshound digitalmars.com> wrote in message
news:c9om10$1n08$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bvp9uf$1hgm$1 digitaldaemon.com...
 Previously, I've tried to use the deprecation facility to change method

 name
 cases to fall in with the D style.

 I recall that there were linker problems.

 That's most likely because what you did was have two names that only
 differed by case. The linker, by default, ignores case and so will produce a
 multiply defined symbol error. The solution is to link with /noi
 (noignorecase).