OO vs. namespaces - doubts
Silas Justiniano
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?
Apologies for my "n00bish" and my bad English :P. Thanks.
Neil Madden
> Hello all!
>
> 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.
Richard Suchenwirth.
>
> 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?
Namespaces are one key part of OO. Using OO shouldn't be harder than
using namespaces, although perhaps things can be a little confusing at
first. Probably the single biggest part that OO systems add over "raw"
namespaces is the ability to instantiate multiple copies of a namespace.
For instance, you might have a "Person" namespace with routines for
operating on data representing people (or customers). You might then
want multiple "instances" to represent different people. One way would
be to separate out the data representing a person from the procedures
that operate on that data, such that you do something like:
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.
-- Neil
Eckhard Lehmann
Silas Justiniano wrote:
> Hello all!
>
> Days ago I was in the Tcler's chat when someone said (Don't remember
Where can I find this chat?
> 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:
Objects are even better for GUI apps. They are especially better in
encapsulation of public and private data and polymorphism (when you
virtually could use more than one instance of 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
Itk, the megawidget extension to Itcl, has a mechanism for that. You
can connect the widgets in an Itk class to object variables with the
[scope] command:
namespace import itcl::
class MW {
inherit itk::Widget
variable entryvar
constructor {args} {
...
entry $itk_interior.e -variable [scope entryvar]
...
}
....
}
> why to use them when you don't need. So, in what way, what kind of
> project, would OO be better than namespaces?
IMHO, any and every project ;-). OO makes the project more flexible,
more extensible and - maybe - it's components more reusable. It also
makes bug fixing a pleasure and fun.
>From my experience most programs start out as little "scripts", just to
ease some things - but with time they grow, because the users open
their mind, they get used to the program, and they want more...
It is much more easy to handle growing and changing projects by using
object techniques rather than simple namespaces. So I start out with
objects in general.
Eckhard
Steve Landers
> Silas Justiniano wrote:
>> Hello all!
>>
>> Days ago I was in the Tcler's chat when someone said (Don't remember
>
> Where can I find this chat?
Follow the directions at http://wiki.tcl.tk/2619
Steve
Silas Justiniano
worried about which of them I should use... I've been reading about
Snit and it changes a lot from my concept of OO (a Java concept,
classes, inheritance, objects...)... I'll find something in the wiki.
Thank you!
Eckhard Lehmann
If you are searching for an object system that works like Java/C++, you
should have a closer look at Itcl/Itk
(http://incrtcl.sourceforge.net/).
Steve, thank you for the link. Looks interresting ;-)!
Eckhard
Ralf Fassel
| Instead of doing [set ::foo foo; set ::bar bar] I just create a
| namespace:
|
| set customers::foo foo
| set customers::bar bar
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.
R'
Donal K. Fellows
> Probably the single biggest part that OO systems add over "raw"
> namespaces is the ability to instantiate multiple copies of a namespace.
Actually, I think it is the ability to encapsulate data and operations
behind a single access interface. Namespaces sort of do it, but only
partially. In Tcl terms, adding an ensemble "accessor" to a namespace
"encapsulator" gives you all you critically need for OO, though command
traces help it all be that bit slicker.
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. :-)
Donal.
Neil Madden
> Neil Madden wrote:
>
>> Probably the single biggest part that OO systems add over "raw"
>> namespaces is the ability to instantiate multiple copies of a namespace.
>
>
> Actually, I think it is the ability to encapsulate data and operations
> behind a single access interface. Namespaces sort of do it, but only
> partially. In Tcl terms, adding an ensemble "accessor" to a namespace
> "encapsulator" gives you all you critically need for OO, though command
> traces help it all be that bit slicker.
Well, I'm curious as to how a namespace + ensemble fails to satisfy
encapsulation and a "single access interface". Also, how do command
traces help here?
-- Neil
Donal K. Fellows
> Well, I'm curious as to how a namespace + ensemble fails to satisfy
> encapsulation and a "single access interface".
Actually my point was that "ns+ens" (plus some conventions) does give
that encapsulation.
> Also, how do command traces help here?
They help with tracking object renaming and especially deletion through
tracking the ensemble command. Allows you to make things *very* slick.
Donal.
Neil Madden
> Neil Madden wrote:
>> Well, I'm curious as to how a namespace + ensemble fails to satisfy
>> encapsulation and a "single access interface".
>
> Actually my point was that "ns+ens" (plus some conventions) does give
> that encapsulation.
Right, so that is not an advantage of OO over namespaces.
>
>> Also, how do command traces help here?
>
> They help with tracking object renaming and especially deletion through
> tracking the ensemble command. Allows you to make things *very* slick.
OK.
-- Neil