[Pharo-project] A radical proposal (to cut down dead code)

Casimiro de Almeida Barreto casimiro.barreto at gmail.com
Mon May 30 15:58:33 EDT 2011

Regarding this subject I think:

   1. There's impossible to authoritatively classify anything as "dead
      code" unless there's a reference standard of what's core and
      what's not core (like, Java defines the JFCs). At this point it
      would be useful to have a reference standard of "core classes" and
      their "core messages/methods".

   2. Having a reference model, it would be nice to have a way
      preventing modifications of core classes inside official
      distribution. Meaning: to be considered part of an official pharo
      distribution, code must not alter foundation classes. That
      shouldn't be an issue due to huge support for inheritance provided
      by smalltalk. So, if need arises to have, let's say, a new
      message/method inside something like Array or OrderedCollection or
      whathever, it's easy to do that simply creating
      MyNewLittleOrderedCollection... It's not hard to verify integrity
      of core classes using digital signatures.

   3. There should be an official policy for marking code as "obsolete"
      or "deprecated".

I guess that once a model of reference classes is established, it's
easier to start profiling things and finding what's alive and what's
dead (not used anymore inside an official distribution). It also
prevents the uncontrolled growth of "core stuff" as consequence of
ad-hoc solutions.

A plus advantage of defining a set of core classes is that it makes easy
to fully document and analyze  them. It allows to ensure several things
that are required for any system to be used in the development of
serious commercial software:

   1. Profiling (theoretical/measured): known algorithms
   2. Security
         1. Regarding continuous operation and up time
         2. Regarding "civilized" use of resources (memory, IO)
         3. Regarding integrity of data
         4. Regarding misuse & unforeseen uses of classes/messages/resources
         5. Regarding privacy
         6. etc...
   3. It makes it possible to have serious end user documentation,
      clearly specifying functionality, interfaces, cases of use,
      limits, error conditions, etc. (side comment: it never went into
      my mind de discourse of "documentation is the code" (moreover when
      some code is not easily understandable)).

My 2¢

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20110530/669a7e6a/attachment.html>

More information about the Pharo-dev mailing list