Version 3 of A Case for OO in the core

Updated 2005-10-08 00:57:30

Philip Quaife 11 Oct 05

Whenever I present my opinion on a subject on this wiki, I try to provide the basis for that opinion. That is to say, I try to provide enough input for someone to provide a rational comment and thus engender a discussion.

In the debate on OO for the core, I have not found any comments made by those people supporting the above so that there can be a rational discussion on the merits.

I have started this page for those people to provide their basis for their viewpoint that:

  • Tcl needs to have OO in the core

TIP 257: Marketing

The TCT have made the statement that marketing forces are sufficient justification.

If we take that as the basis, then I propose that there are more deserving marketing issues for Tcl, namely:

  1. Distribution. A formal method of making stand alone executables,.
  2. Database interaction.
  3. Web plugin.
  4. 3D Graphics.

None of the above are included or even distributed with the core. Since the TCT are the sponsers of tip257, they would have sponsered the above as TIP's if they had a genuine interest in marketing forces.

 I propose:
  • That the marketing argument is specious.

There is a need for OO in the core

I need chocolate might as well be the phrase stated. There have not been any stated examples that show that Tcl would be 'better' or that development in Tcl would be 'easier' if OO was in the core.

I propose:

  • That the need is emotional not factual.

OO Programmes are Better

Lets provide a simple definition of better. If OO leads to less code, more stable applications, less effort for programmers, then we can generalise and say that overall we have a better situation. I would also say that adding features to a programme does not count as making it a better application. For example, FireFox is not better than Netscape because it has more features, it would be a better application if it took less code for the same features, was more reliable.

The problem is providing concrete examples to provide as a comparison. This is the best I can come up with as a valid example.

  1. TeX
  2. Mozilla

Both of the above applications have the same function. They take an abstract representation of the content of a document and create a formatted document for the purpose of viewing or printing. Both in the wider sense are still in development.

Lets just take one aspect as proof of the point.

  1. Take the source code for e-tex, add in the code for the macros. Now add in the code for the LaTeX macros. Also add in the code for Xdvi.
  2. Take the source code for the table layout of Gecko.

If we compare these we find that there is more source code in the table layout code for Mozilla than there is in the entire TeX system!

Since bugs are proportional to the number of lines of code, TeX must be more reliable than Mozilla.

One of the tenents of OO is Code Reuse, we should see that as more features are added to Mozilla, the less code is required. Since all new features are based on existing code, bug fixes in the old code should result in less bug fixes being required in the new code. From an OO point of view, there should be less code in Gecko than is required for TeX macros. The reverse situation is true.

I propose that:

  • The number of bug in mozilla is not reducing as OO design practices would dictate.
  • The amount of source code (ie new classes) for new features for mozilla is not reducing as OO design practices would dictate.
  • There is more effort required in maintaning Mozilla than there is in TeX.

I propose from the above

  • TeX is more reliable than Mozilla.
  • pascal/C are better than C++
  • Procedual is better than Object oriented

aricb Dude, you are missing the point. The case for OO in the core is this:

Lots of people want OO in the core because they want OO in the core. They can probably articulate a reason or two, but it ultimately comes down to personal preference, which needn't be subjected to silly debates. In the end, those same people will still want OO in the core, and you still won't.

It seems silly to fight a TIP whose inclusion needn't affect the way you use Tcl. You can still go on writing procedural code if TIP 257 is accepted. If you're concerned about the impact of this TIP on the size of the Tcl executable, just stick to Tcl 8.4; you seem quite satisfied with Tcl's status quo anyway.