On 19 Apr 2001 20:15:08 -0400, Dom Lachowicz wrote:
>
> Public virtual methods are fine. It just means that a subclass can override
> them.
It means that a subclass can override them *and* that a non related
class can call them. And I don't think that they are always fine, but I
will not try to push/discuss this change right now.
> Java does this for free. C++ does not, so you have to explicitly mark
> them yourself.
> Think of the distinction between interface vs. data and the
> fact that someone else might want to usefully subclass your public class. If
> you don't want anyone to subclass you, take the appropriate steps to see
> that this doesn't happen.
> Take the time to give appropriate scope to your
> methods, especially your accessor methods. Please give appropriate scope to
> all methods in your class. It's worth taking the time to do things correctly
> the 1st time. Really :-)
Amen.
>
> >However, if it's important enough to others that they're willing to make
> >the
> >current sources compliant with the proposed standard, then I'll stay out of
> >their way. Gladly.
>
> The task is not impossible or not-worthwhile. It's just daunting.
>
> <snip>
>
> >Then we disagree. For me a standard is a standard, period, or else it's
> >worthless.
> >If this one isn't important enough to fix, then it shouldn't be a standard.
>
> 100% agree. Here, I'm for a "all new code gets written to the new standard
> while we transition out the old standard." The govm't does exactly this with
> its laws on say, refrigerants. CFCs have been banned, but if you're using
> them in a current system, you're granted immunity for N time to transition
> to the new standard. You're not exactly in violation, but you won't be able
> to get anything new done to you.
but if I understand Paul, he is saying something like:
#1 "don't change what the standard say unless you first change the code"
and you're saying something like:
#2 "it's fine to change the standard and make the changes gradually"
I vote for #2, too.
> motto: don't sacrifice current quality just because your older product might
> not have been of the same standard
Amen.
Cheers,
--
Joaquín Cuenca Abela
[EMAIL PROTECTED]
