Re: The $VERSION crusade

[Raphael Manfredi <Raphael.Manfredi@st.com>]

[Sorry to jump in the discussion only right now, but I was on business trip
 and vacation since December 1st, and I went through all my perl5 folder
 quite rapidly--RAM]

Quoting m.pearce@inpharmatica.co.uk:
:| What I generally specify is:
:| 
:| 	Exported Variables
:| 	Public Methods/Subs
:| 	Private Methods/Subs
:
:Sounds familiar.  I haven't seen any comment from Larry, Sarathy, Tom,
:or similar.  If this idea has any support from the core team, I suggest
:that we pool ideas for standards, and come up with something coherent,
:and hopefully popular (since it won't work without popularity).  I would 
:be willing to act as a collector of ideas on this.

Tsk... You're re-inventing Eiffel. ;-)

One outburst on the public/protected/private issue:

There should not be anything declared "private". Everything should be
either public, or protected (implicitely, when not forced public). Doing
otherwise prevents reuse and is against the Open-Closed principle (the
class is "closed" i.e. usable, and offers a consistent set of features,
but remains "open" because it can be inherited from and have its feature
set extended or redefined).

Inheriting from a class to redefine/extend the feature set it not
something to be taken lightly. You need to understand the internals of
the parent class, and therefore the "private" protection is useless, or
might force you to duplicate some code that you would otherwise reuse.

This is the Eiffel model of inheritance, and it makes a lot of sense.
I choked many C++ programmers once by defending this point of view.
However, something C++ is badly missing is pre- and post- conditions,
as well as class invariants. Eiffel has those natively, and naturally,
they are *inherited* on a feature/class basis.

This means no-one can ever redefine you 'perimeter' feature in POLYGON
to compute the surface, if you have a post-condition in POLYGON expressing
that the result should be the sum of the length of all the vertices
of the POLYGON. You may redefined 'permiter' in RECTANGLE, or SQUARE,
but you're constrained by the post-condition set in POLYGON.

Class invariants also prevent abusive inheritance. In class RECTANGLE,
you may say that "nb_vertices == 4". And therefore, SQUARE may inherit
from RECTANGLE, but not TRIANGLE, because it cannot satisfy the invariant,
which is inherited along.

:| Some people may object to specifying private stuff in the documentation,
:| preferring that private stuff is only known to the module developer;
:| that's a semi-philosophical point, I guess. 
:
:This is the kind of issue that would need be be thrashed out.
:Unfortunately, this approaches the issue of coding standards --- so we
:need to be clear on what *wouldn't* be a topic for discussion...

I assume you mean "protected" when you say "private". ;-)

Anyway, it depends whom the documentation targets. If you're explaining
someone how to inherit and extend your class, describing the protected
(let's say "internal") stuff is necessary. If you're targetting the
"user" (i.e. the "client" of the class), only the external features need
to be specified, along with the necessary pre- and post- conditions as
well as invariants that may be informally expressed.

Raphael

---

References to:

Martyn Pearce <m.pearce@inpharmatica.co.uk>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---