OO and TIP#257 
Author Message
 OO and TIP#257

I've posted this to Wiki page http://www.*-*-*.com/
TIP#257, but I thought more people may see it here ;)

Regards,
Twylite
---

Do we need OO support in the core?  Yes.  The many reasons include that
the community obviously wants to have OO available (witness the number
of extensions) and without core support the extensions may not be
available on your platform / distribution or may be unacceptably slow.

That said, there is a huge difference between OO _support_ in the core,
and the XOTcl-like core functionality proposed by TIP#257.

The purpose of OO support, and the stated purpose of TIP#257, is to
allow OO systems to be built on top of that support.  Of course TIP#257
will also provide a fully functional OO system in its own right, in
order to meet the requirement that code can use a decent OO system
without having to rely on an extension being present.  This is a Good
Thing IMHO.

My concerns with TIP#257 are that (1) it tries to offer too much, (2) it
doesn't "feel" like Tcl, and (3) it pushes out the availability of 8.5.

I feel that is it essential to develop a _simple_ system now, and add
more functionality later if it is required -- you can always add on
later, but you can't take out what you put in now!

---

(1) A huge part of Tcl's value (IMHO) comes from being easy to learn,
which makes it important to strive for simplicity and consistency in the
core (yes, I know this doesn't always happen).  I really don't think
that filters or forwarders/delegation belong in this TIP.  Sure, they
are useful -- especially in the context of objects -- but they're not
specific functionality of an object system or essential for basic OO
support.

Filters need to be part of a separate TIP that will consider their
applicability to classes, objects, namespaces and globally.  Forwarders
would also have value globally, as a more powerful and more intuitive
alternative to "interp alias", and a mechanism to implement aspects
efficiently.

---

(2) Let me illustrate what I mean by "it doesn't feel like Tcl".
Imagine defining a namespace proc like this:
   namespace myns proc myproc {args} {body}
That's pretty much what TIP#257 is suggesting:
   oo::define myclass method myname {args} {body}

I believe that the majority of Tcl developers see OO as a logical
extension to the namespace mechanism.  I would expect a purely static
class not just to look like a namespace, but to _be_ a namespace.  I
would also expect member visibility and class resolution to use the same
mechanisms as namespaces: namespace export and namespace path.
Something like this "feels" right to me:

--
namespace eval myclass {

   # class variable
   variable x

   # member/instance variables
   instvariable y
   instvariable -publicy

   # superclasses ; we could use "inherit" as syntactic spice for
   #   "namespace path".
   namespace path classA classB

   # class method
   proc classProcA {args} {body}

   # instance method
   method instMethodA {args} {body}
   method _privInstMethodB {args} {body}

   # constructor
   constructor {args} {body}

   # destructor
   destructor {body}

   # declare public/visible methods, as for "namespace ensemble"
   namespace export classProcA instMethodA configure cget

   # Here's some cross-cutting functionality using syntax from TIP#TBD
   forward cget ::oo::cget
   forward configure ::oo::configure
   forward log ::mylog::do_log -src myclass
     # args to log are tacked on after "-src myclass", as with
     # "interp alias"

Quote:
}

--

All procs, methods, and the constructor/destructor could be declared
outside the "namespace eval" using qualified names:
   method myclass::instMethodB {args} {body}

Next, class and instance variables must be explicitly pulled into a
proc/method, using "variable" and "instvariable".  This is consistent
with the rest of Tcl, and is a Damn Good Thing because it makes it a
whole lot easier to analyse procs and methods for invalid references.
The assumption that all variable references are local unless qualified
is fundamental to Tcl, and shouldn't be violated.

--
method myclass:instMethodB {args} {
   variable x
   instvariable y

   # This will throw an error because -publicy isn't in scope
   puts ${-publicy}

Quote:
}

--

I would expect to create objects using something like this (*):
   set inst [myclass new]  ;# auto naming
   set inst [myclass new instname]
and call them like this:
   $inst methodname arg arg ...
   myclass procname arg arg ...
and destroy them like this:
   destroy $inst

Within an instance I should be able to call an instance method without
qualification or using "self" or "$self", in the same way as namespace
procs can call each other.  I know this is technically less than simple ;(

(*) This is different to Tk widget instantiation, but Tk widget classes
(a) don't have class methods and (b) require a name.  If you allow
"myclass instname" to create an object then you end up with objects
floating around whenever you call a class method that doesn't exist.  Ick!

A namespace can be assumed to represent a class if any of { method
instavariable constructor } are defined.  Default methods that are
typically available to all instances, like "info" and "eval", can be
added to objects automatically.

I am aware that I have not addressed all aspects of an OO system here --
these are just the basics that I feel TIP#257 isn't getting right.  The
rest of an OO system flows around these basics.

---

(3) I'd also like to make the point that the world is waiting for Tcl
8.5 and its numerous enhancements.

It seems to me that proposals like OO and Tile need to be more mature,
and left for an 8.6 release.

This also makes sense considering the wealth of 8.5 functionality that
has already been implemented (or is planned) and benefits or is meant to
benefit OO extensions:
- TIP#103 {expand}
- TIP#112 ensembles
- TIP#181 namespace unknown
- TIP#229 scripted resolution in namespaces
- TIP#250 access to namespace variables
- leading word expansion

Let's give the Tcl community an opportunity to work these enhancements
into OO systems, and see what evolves, what is still missing, and what
is appropriate to become core functionality for 8.6.

My 2c towards a happy Easter ;)



Mon, 29 Sep 2008 21:52:17 GMT  
 OO and TIP#257
It seems to me that the oo stuff in not set in stone yet and if that is
the case, then yes, I would rather see a move to get 8.5 out the door
and get the oo stuff in 8.6. We don't need to rush it.

My 2c...

Robert



Mon, 29 Sep 2008 22:17:32 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Status of Tip 257?

2. TIP #257: Object Orientation for Tcl

3. [Fwd: TIP #257: Object Orientation for Tcl]

4. expect: send > 257 characters on Solaris

5. PEP 257: Docstring Conventions

6. 'Driver Error (-257): tag in use' during convert

7. Block handling tips (was : File handling tips )

8. Tips.Tips Introduction

9. TIP #13: Web Service for Drafting and Archiving TIPs

10. SENIOR OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

11. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

12. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

 

 
Powered by phpBB® Forum Software