From: Mike Schilling on
Andreas Leitgeb wrote:
> Mike Schilling <mscottschilling(a)hotmail.com> wrote:
>> Do you really not know what I mean? Fine I'll be more explicit.
>
> I do think I did understand you, but I think you see it too narrow.
> Whatever you said about non-documented (by experimentation) uses of
> a particular API apply to plain use as well as to subclassing.
>
> In any way it's not the vendor's "duty"/obligation to do anything
> more than place a note in the doc warning against subclassing some
> class, to be free to change undocumented features, later, at will.
>
>> Either way, A should be defined as final. Becasue the alternative
>> is
>> that V2 of the library can break existing clients.
>
> But only those who "deserve" it, for not following the docs, and
> quite
> likely not even all of them.

If I thought that "The docs tell you not to do that, therefore you
have no right to complain when it doesn't work" was effective, well, I
probably wouldn't have worked in software for thirty years. Actually,
I spent much of last week helping a customer who'd fouled up their
persistent storage by doing two things that we specifically document
as not supported. They're an important one, so saying "You made your
bed, now lie in it" was not an option.


From: Rzeźnik on
On 14 Paź, 19:22, "Mike Schilling" <mscottschill...(a)hotmail.com>
wrote:
> Rzeznik wrote:
> > On 14 Paz, 19:06, Leif Roar Moldskred
> > <le...(a)huldreheim.homelinux.org>
> > wrote:
> >> Alessio Stalla <alessiosta...(a)gmail.com> wrote:
> >>> Documentation is sufficient to "signal".
>
> >> To the typical software developer? Not in my experience.
>
> > Who is a typical software developer? Someone who does not read docs?
>
> Yes.

Not in my experience.
From: Leif Roar Moldskred on
Andreas Leitgeb <avl(a)gamma.logic.tuwien.ac.at> wrote:
>
> And even if so, why do you (Leif, Mike, etc) feel obliged to prevent him
> from shooting his toes off?
>

Because I'm a professional and I don't do shoddy work, and because I prefer
working with clearly defined APIs myself, so that's what I try to make.

--
Leif Roar Moldskred
From: Rzeźnik on
On 14 Paź, 19:28, "Mike Schilling" <mscottschill...(a)hotmail.com>
wrote:
> Andreas Leitgeb wrote:
> > Mike Schilling <mscottschill...(a)hotmail.com> wrote:
> >> Do you really not know what I mean?   Fine I'll be more explicit.
>
> > I do think I did understand you, but I think you see it too narrow.
> > Whatever you said about non-documented (by experimentation) uses of
> > a particular API  apply to plain use as well as to subclassing.
>
> > In any way it's not the vendor's "duty"/obligation to do anything
> > more than place a note in the doc warning against subclassing some
> > class, to be free to change undocumented features, later, at will.
>
> >> Either way, A should be defined as final.  Becasue the alternative
> >> is
> >> that V2 of the library can break existing clients.
>
> > But only those who "deserve" it, for not following the docs, and
> > quite
> > likely not even all of them.
>
> If I thought that "The docs tell you not to do that, therefore you
> have no right to complain when it doesn't work" was effective, well, I
> probably wouldn't have worked in software for thirty years.  Actually,
> I spent much of last week helping a customer who'd fouled up their
> persistent storage by doing two things that we specifically document
> as not supported.  They're an important one, so saying "You made your
> bed, now lie in it" was not an option.

You know the difference between development and support, right? By the
way, no one tells you to abandon your customer, you are not helping
him out of charity anyway. And as I said before - if you are writing
proprietary software it is easier for you to justify your opinions (do
not take it for granted though)
From: Rzeźnik on
On 14 Paź, 19:37, Leif Roar Moldskred <le...(a)huldreheim.homelinux.org>
wrote:
> Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at> wrote:
>
> > And even if so, why do you (Leif, Mike, etc) feel obliged to prevent him
> > from shooting his toes off?
>
> Because I'm a professional and I don't do shoddy work, and because I prefer
> working with clearly defined APIs myself, so that's what I try to make.
>

That's deceptive to think that API is "clearer" because of extensive
use of finals, and if you believe that your work is less/more 'shoddy'
because of finals, you are lying to yourself.