Days ago I was in the Tcler's chat when someone said (Don't remember
now... probably Richard Suchenwi[something]) some new namespace feature
in 8.5 would be great, then Jeff (Jeffrey Hobbs) said that OO should be
more important than simple namespace improvement.

I've discovered that namespaces are so good for GUI apps. Suppose for
example I need a "Customer" table and it has many fields. Therefore,
the toplevel has to have many [entry] connected to many variables. As
those variables must be global, to be available in every proc. Instead
of doing [set ::foo foo; set ::bar bar] I just create a namespace:

  set customers::foo foo
  set customers::bar bar

When closing the window, I destroy the namespace. It works quite well
for apps like that, I don't know better way.

What about OO? It does the same, but in a harder way. I've been using
Snit for a little time, it is very good, but makes hard simple things
like that. It's probably more useful for harder and bigger things. I
probably had never needed advanced OO for anything and I even can't
understand it correctly, that's one of the reasons that I do not see
why to use them when you don't need. So, in what way, what kind of
project, would OO be better than namespaces?

set person [person create ...]
puts "[person name $person] is [person age $person] years old"

What $person contains depends on how you decide to implement individual
people -- it could be a list or dictionary of data values, or it could
be an opaque handle that is used to index an array in the person
namespace, or something else. You have to implement this yourself,
generally. An OO system provides a means of doing this so you don't have
to write your own. In addition, OO systems usually provide some form of
encapsulation whereby data is wrapped up with methods that operate on
it, often by making $person a command:

set person [person create ...]
puts "[$person name] is [$person age] years old"

That's probably the absolute bare minimum for an "object-like"
interface. Things like [namespace ensemble] (in 8.5) provide much of
what is required for this using Tcl's in-built namespaces. OO extensions
tend to provide a nicer interface, though, taking care of some of the
details. Defining exactly what "OO" is beyond this is more open to
debate, as there are a variety of different functionalities that are
considered key to OO by different parties. Some OO systems organise code
into classes (or types) which can then be instantiated, others allow you
to clone any object to create a new instance. Some OO systems support
inheritance as a means to reuse the implementation of another class (and
acquire its interface), whereas others prefer delegation/forwarding (as
in Snit). OO systems generally support some form of ad-hoc polymorphism
(or overloading) which allows different object/classes to implement the
same named operation in different ways. It is generally better to
consider which of these individual features you want, rather than to
make a blanket OO/non-OO decision--many of the features can be achieved
by other means.

If namespaces are working for you now, then that's great. They are a
powerful mechanism and quite flexible (especially with the new features
in 8.5). If you've not used an OO system before, I would certainly
recommend learning one (snit is a good choice), as I would recommend
learning any new way of approaching programming. I wouldn't worry too
much about the proposed standard OO system (TIP 257) as it should be
compatible with existing OO systems (i.e., they won't break because of
its presence, and they could benefit from building on it) and with the
existing namespace infrastructure.

namespace import itcl::

class MW {
    inherit itk::Widget

    variable entryvar

    constructor {args} {
        ...
        entry $itk_interior.e -variable [scope entryvar]
        ...
    }
    ....

Steve, thank you for the link. Looks interresting ;-)!

Just to mention one example, just think about what will happen if you
have more of these variables, and then you need to add value-checking
to your app (one variable needs all-uppercase, the other is a date
etc).  With OO, you don't have global variables, but methods to set
the data.  Adding a check to a method is easy compared to finding all
occurences where you set a global variable.  Yes, with a bit of
discipline, one can manage without OO, but it's easier with the
support of a OO system.

The next big step up over that is class/prototype-based OO. That's much
more complicated, but adds a lot too. Or would if Tcl wasn't so friendly
to just writing generic code anyway. :-)