Error processing request

Parameters

Body

Error

Unknow state transition: LINE -> END

-code

1

-level

0

-errorstack

INNER {returnImm {Unknow state transition: LINE -> END} {}} CALL {my render_wikit {Integrating Itcl into the Tcl core} The\ issue\ in\ the\ page\ title\ is\ an\ extended\ subplot\ in\ the\ history\ of\ Tcl\ development.\ Among\ the\ milestones\ are\ the\ \[TIP\]s:\n\ \ \ #6:\ \ \ ''Include\ \[Incr\ Tcl\]\ in\ the\ Core\ Tcl\ distribution''\ \[http://tip.tcl.tk/6\]\ (rejected)\n\ \ \ #50:\ \ \ ''Bundle\ \[incr\ Tcl\]\ with\ the\ Core\ Tcl\ distribution''\ \[http://tip.tcl.tk/50\]\ (accepted,\ but\ never\ implemented)\n\ \ \ #257:\ \ \ ''Object\ Orientation\ for\ Tcl''\ \[http://tip.tcl.tk/257\]\ (still\ draft)\nIn\ early\ 2007,\ the\ state\ of\ the\ matter\ seems\ to\ be\ that\ acceptance\ of\ TIP\ #257\ will\ make\ the\ matter\ moot\ (it\ won't\ be\ Itcl,\ but\ chances\ are\ that\ noone\ will\ mind\ the\ difference).\ What\ follows\ below\ is\ therefore\ more\ of\ historical\ interest,\ but\ it\ still\ seems\ to\ be\ a\ very\ thorough\ analysis.\n\n----\n\nA\ position\ paper\ by\ Mo\ DeJong.\n''If\ you\ have\ been\ underground\ for\ some\ time\ (perhaps\ waiting\ for\ the\ US\ elections\ to\ end),\ you\ might\ not\ have\ heard\ about\ the\ recent\ talk\ of\ adding\ \[Itcl\]\ to\ the\ \[Tcl\]\ core.''\n\n''I\ took\ it\ upon\ myself\ to\ compile\ a\ list\ of\ some\ of\ the\ issues\ that\ were\ brought\ up\ by\ this\ whole\ \"Integrating\ Itcl\"\ discussion.\ Note\ that\ this\ paper\ has\ not\ been\ proof\ read,\ so\ please\ try\ to\ ignore\ any\ stupid\ spelling\ errors\ and\ the\ like\ :)''\n\ncheers\ -\nMo\ DeJong\ -\nRed\ Hat\ Inc\n----\n\nWhat\ exactly\ am\ I\ talking\ about?\n\n'''Question:'''\nWhat\ is\ the\ best\ way\ to\ integrate\ Object\ Oriented\ functionality\ into\ the\ Tcl\ core?\n\n'''Answer:'''\nIntegrating\ the\ OO\ features\ provided\ by\ Itcl\ into\ the\ Tcl\ core.\ Itcl\ will\ provide\ the\ OO\ support\ that\ programmers\ desperately\ need.\ The\ trick\ here\ will\ be\ doing\ this\ in\ a\ way\ that\ maintains\ the\ \"Tao\ of\ Tcl\".\n\n\ \ \ *\ Not\ talking\ about\ adding\ the\ Itcl\ package\ to\ the\ Tcl\ core.\n\n\ \ \ *\ Not\ talking\ about\ adding\ the\ Itcl\ namespace\ to\ the\ Tcl\ core.\n\nFor\ example,\ there\ would\ be\ no\ itcl::class\ command.\ The\ class\ command\ would\ become\ a\ new\ global\ command.\n\n\ \ \ *\ Itcl\ would\ cease\ to\ exist\ after\ being\ integrated\ into\ the\ core.\n\nThe\ OO\ functionality\ provided\ by\ Itcl\ would\ become\ a\ standard\ part\ of\ the\ Tcl\ language,\ Itcl\ as\ a\ separate\ entity\ would\ cease\ to\ exist\ except\ for\ use\ in\ backwards\ compatibility.\n\n\ \ \ *\ Talking\ about\ doing\ this\ for\ Tcl\ 9.0.\n\nOO\ support\ in\ Tcl\ is\ a\ major\ new\ feature,\ it\ cries\ out\ for\ a\ new\ major\ release\ number.\ Existing\ Itcl\ users\ are\ going\ to\ have\ to\ update\ scripts\ to\ make\ best\ use\ of\ this\ new\ OO\ system.\ Existing\ Tcl\ users\ will\ run\ into\ problems\ is\ they\ define\ commands\ like\ body,\ class,\ or\ the\ like.\ Moving\ to\ a\ new\ major\ release\ will\ give\ users\ an\ obvious\ indication\ that\ they\ may\ need\ to\ re-examine\ script\ during\ an\ upgrade.\n\nWhat\ exactly\ does\ \"Integrate\ Itcl\"\ mean?\nWell,\ it\ depends\ on\ who\ you\ ask.\n\n\ \ \ *\ Some\ will\ tell\ you\ that\ the\ only\ option\ is\ to\ move\ the\ existing\ Itcl\ source\ code\ into\ the\ Tcl\ CVS\ and\ live\ with\ any\ consequences\ or\ incompatibilities.\n\n\ \ \ *\ Some\ will\ tell\ you\ that\ the\ only\ solution\ is\ to\ keep\ Itcl\ as\ a\ separate\ package.\ The\ thinking\ here\ seems\ to\ be\ that\ adding\ OO\ features\ directly\ to\ the\ Tcl\ language\ will\ destroy\ the\ \"procedural\ purity\"\ of\ Tcl.\n\n-\ I\ think\ that\ most\ will\ conclude\ that\ the\ real\ solution\ lies\ somewhere\ between\ these\ extremes.\n\n-\ The\ whole\ notion\ of\ \"compatibility\"\ is\ a\ double\ edged\ sword.\ While\ it\ does\ help\ to\ keep\ old\ code\ working,\ it\ also\ can\ lead\ to\ lack\ of\ improvement\ for\ fear\ of\ effecting\ existing\ code.\n\nWhen\ it\ comes\ to\ integrating\ Itcl\ into\ Tcl,\ compatibility\ with\ existing\ or\ older\ versions\ of\ Itcl\ is\ not\ the\ overwhelming\ concern.\ The\ solution\ that\ has\ been\ discussed\ is\ to\ provide\ a\ backward\ compatibility\ layer\ that\ would\ map\ to\ Itcl\ 3.0\ only.\ This\ would\ provide\ an\ upgrade\ path\ to\ those\ folks\ currently\ running\ with\ Itcl\ 3.0.\n\n'''Change\ is\ bad:'''\n\n-\ Some\ believe\ quite\ strongly\ that\ to\ change\ anything\ about\ Itcl\ is\ an\ attack\ on\ every\ Itcl\ user.\ One\ person\ described\ any\ modification\ to\ Itcl's\ syntax\ or\ semantics\ as\ \"spitting\ in\ the\ eye\ of\ every\ Itcl\ user\".\n\n-\ Others\ contend\ that\ Itcl\ is\ so\ widely\ used\ that\ it\ simply\ must\ be\ \"right\".\ It\ is\ described\ as\ a\ \"proven\ technology\"\ so\ no\ changes\ could\ possibly\ improve\ it.\n\n-\ Still\ others\ content\ that\ \"now\ is\ not\ the\ time\ to\ make\ changes\".\ The\ reasons\ given\ are\ an\ extreme\ sense\ of\ urgency,\ a\ belief\ that\ any\ change\ will\ be\ impossible\ to\ implement,\ or\ that\ anyone\ other\ than\ the\ original\ author\ is\ simply\ unqualified\ to\ even\ suggest\ changes.\n\nI\ have\ asked\ the\ question\ before,\ but\ have\ yet\ to\ hear\ an\ answer.\ If\ not\ now,\ when\ would\ be\ a\ better\ time\ to\ change\ Itcl?\ After\ a\ larger\ base\ of\ Tcl\ users\ have\ begun\ to\ build\ software\ on\ the\ combined\ Tcl+OO\ interface?\ After\ new\ Tcl\ 9.0\ books\ are\ published?\ When\ exactly?\n\n-\ If\ you\ are\ unwilling\ to\ consider\ any\ changes\ to\ Itcl,\ you\ should\ stop\ reading\ now.\n\n'''Change\ is\ good.'''\n\n-\ Improved\ OO\ integration\ can\ lead\ to\ an\ easier\ to\ use\ system.\ Far\ too\ many\ people\ avoid\ Tcl\ because\ they\ hear\ oversimplifications\ like\ \"there\ is\ no\ OO\ in\ Tcl\".\ We\ need\ to\ extend\ the\ Tcl\ user\ base,\ not\ worry\ about\ the\ significantly\ smaller\ group\ of\ existing\ Itcl\ users.\n\n-\ Avoiding\ \"legacy\ issues\"\ is\ a\ serious\ concern.\ What\ seems\ simple\ to\ one\ person\ may\ not\ be\ simple\ to\ someone\ else.\ In\ five\ years,\ nobody\ is\ going\ to\ care\ if\ Itcl\ defined\ the\ variable\ command\ before\ the\ Tcl\ core\ did.\ They\ are\ going\ to\ care\ if\ confusing\ incompatibilities\ exist,\ and\ can\ not\ be\ removed\ because\ of\ backward\ compatibility\ concerns.\n\n-\ Itcl\ contains\ a\ number\ of\ features\ and\ concepts\ that\ are\ fundamentally\ at\ odds\ with\ Tcl.\ If\ we\ avoid\ addressing\ these\ issues\ now\ out\ of\ a\ sense\ of\ expediency,\ we\ could\ be\ making\ it\ harder\ to\ maintain\ and\ improve\ Tcl\ in\ the\ future.\n\n-\ Itcl\ is\ no\ different\ than\ any\ other\ extension.\ It\ is\ not\ \"special\".\ If\ there\ are\ incompatibilities,\ then\ they\ need\ to\ be\ worked\ out\ before\ the\ code\ is\ integrated,\ not\ after.\ We\ can\ not\ subscribe\ to\ the\ theory\ that\ some\ parts\ of\ Tcl\ are\ \"off\ limits\".\n\n-\ Provide\ compatibility\ layer\ for\ older\ code.\ This\ is\ the\ same\ approach\ used\ by\ Itcl\ in\ previous\ releases.\ This\ time,\ it\ would\ be\ implemented\ with\ a\ Tcl\ only\ package\ instead\ of\ keeping\ a\ bunch\ of\ old\ C\ code\ around.\n\n-\ Any\ change\ is\ going\ to\ require\ a\ bit\ of\ rewriting\ and\ updating.\ We\ should\ focus\ on\ how\ we\ can\ improve\ the\ users\ transition\ with\ tools\ like\ the\ Tcl-Pro\ Checker\ and\ Source-Navigator.\n\n'''Itcl\ misconceptions.'''\n\n-\ A\ common\ theme\ seems\ to\ be:\n\n\"Itcl\ has\ been\ stable\ for\ 8\ years,\ you\ can't\ change\ it\ now!\"\n\nIn\ reality,\ there\ have\ been\ major\ overhauls\ of\ the\ syntax\ and\ semantics\ of\ Itcl\ during\ the\ 1.X\ ->\ 2.X\ ->\ 3.X\ transitions.\n\nSome\ have\ contended\ that\ these\ have\ been\ \"minor\ improvements\"\ and\ that\ they\ don't\ matter\ because\ backward\ compatibility\ was\ retained\ along\ the\ way.\ Ironically,\ this\ is\ not\ much\ different\ than\ what\ I\ am\ suggesting.\n\n-\ Itcl\ is\ just\ like\ C++\n\nItcl\ is\ not\ so\ similar\ to\ C++\ that\ it\ is\ immediately\ intuitive.\ There\ are\ plenty\ of\ concepts\ that\ just\ don't\ translate\ between\ the\ two.\ Many\ of\ them\ are\ rooted\ in\ the\ interpreted\ native\ of\ Tcl\ itself.\ \ Some\ diffs\ between\ C++\ and\ Itcl:\n\n-\ the\ access\ keywords\ are\ the\ same\ as\ c++\ but\ the\ defaults\ access\ is\ not.\n\n-\ That\ static\ modifier\ is\ not\ really\ the\ same\ concept\ as\ \"common\".\ The\ static\ modifier\ in\ C++\ is\ applied\ to\ both\ methods\ and\ data.\ Itcl\ generally\ avoids\ the\ concept\ of\ a\ \"modifier\".\ Itcl\ uses\ a\ different\ command\ for\ each\ type\ of\ declaration\ (proc,\ method,\ common,\ variable).\ There\ is\ of\ course\ an\ exception,\ Itcl\ uses\ modifiers\ for\ access\ control\ (public,\ private,\ protected).\n\n-\ Itcl\ is\ bug\ free!\n\nMy\ own\ experience\ seems\ to\ contradict\ the\ assertion\ that\ Itcl\ is\ as\ stable\ as\ the\ Tcl\ core.\n\nI\ have\ used\ Itcl\ sparingly\ in\ the\ past,\ mostly\ because\ it\ was\ not\ part\ of\ the\ \"core\"\ so\ you\ really\ could\ not\ depend\ in\ it\ being\ installed.\n\nI\ now\ hack\ on\ Itcl\ code\ full\ time.\ I\ have\ seen\ many\ of\ the\ legacy\ issues\ from\ the\ perspective\ of\ a\ user\ with\ a\ large\ Itcl\ code-base.\ I\ think\ it\ is\ safe\ to\ say\ that\ Itcl\ is\ not\ as\ stable\ as\ the\ Tcl\ core.\n\nFor\ example,\ a\ new\ C++\ programmer\ might\ try:\n\n======\n\ \ itcl::class\ Toaster\ \{\n\ \ \ \ Toaster\ \{\ name\ \}\ \{\n\ \ \ \ \ \ \ \ puts\ \"Just\ created\ a\ toaster\ named\ \$name\"\n\ \ \ \ \}\n\n\ \ \ \ method\ toastme\ \{\ \}\ \{\n\ \ \ \ \ \ \ \ after\ 5000\ \"set\ toast_done\ 1\"\n\ \ \ \ \ \ \ \ vwait\ toast_done\n\ \ \ \ \}\n\ \ \}\n\n\ \ Segmentation\ fault\n======\n\nClearly,\ this\ is\ not\ the\ most\ effective\ feedback\ Itcl\ could\ provide.\n\nThe\ point\ here\ is\ not\ to\ pick\ on\ Itcl.\ It\ is\ clear\ that\ much\ of\ the\ code\ in\ Itcl\ is\ well\ tested.\ However,\ there\ can\ be\ no\ doubt\ that\ there\ are\ far\ fewer\ Itcl\ users\ than\ there\ are\ Tcl\ users.\ There\ can\ also\ be\ no\ doubt\ that\ Itcl\ has\ historically\ had\ less\ \"support\"\ than\ the\ Tcl\ core.\ With\ fewer\ people\ working\ with\ the\ code\ from\ day\ to\ day,\ nasty\ corner\ cases\ are\ more\ likely\ to\ go\ undetected.\ Only\ by\ incorporating\ the\ OO\ functionality\ provided\ by\ Itcl,\ will\ the\ last\ of\ these\ bugs\ be\ worked\ out.\ I\ would\ hope\ that\ we\ can\ dispense\ with\ the\ notion\ that\ there\ are\ no\ bugs\ in\ Itcl\ and\ move\ forward.\n\n'''What\ concepts/commands\ does\ Itcl\ add?'''\n\n\ -\ classes\n\ -\ instances\ (objects)\n\ -\ instance\ methods\n\ -\ instance\ variables\n\ -\ class\ wide\ methods\ (class\ procs)\n\ -\ access\ control\ for\ methods\n\ -\ automatic\ scoping\ of\ variables\n\ -\ inheritance\ and\ multiple\ inheritance\n\nLet's\ ignore\ the\ older\ backwards\ compatibility\ commands\ included\ in\ Itcl\ 3.0\ for\ the\ sake\ of\ brevity\ here.\ When\ we\ talk\ of\ \"Integrating\ Itcl\"\ what\ we\ are\ really\ talking\ about\ is\ moving\ the\ following\ commands\ from\ the\ itcl\ namespace\ and\ defining\ them\ as\ global\ Tcl\ commands.\n\n\ local\n\ class\n\ body\n\ configbody\n\ ensemble\n\ find\n\ scope\n\ code\n\ delete\n\nIn\ addition,\ there\ are\ the\ commands\ that\ are\ only\ accessible\ while\ a\nclass\ declaration\ is\ being\ evaluated.\ These\ commands\ include:\n\n\ private\n\ protected\n\ public\n\ variable\n\ common\n\ method\n\ proc\n\ constructor\n\ destructor\n\ inherit\n\n'''Object\ creation\ and\ destruction'''\n\nOne\ of\ the\ most\ fundamental\ questions\ that\ needs\ to\ be\ addressed\ is\ how\nobjects\ will\ be\ created\ and\ destroyed.\ Having\ a\ multitude\ of\ ways\ to\ncreate/destroy\ objects\ is\ just\ plain\ confusing.\ We\ must\ define\ the\n\"preferred\ method\"\ of\ object\ allocation\ and\ destruction.\n\nSome\ have\ suggested\ that\ a\ \"new\"\ command\ should\ be\ introduced.\ This\ command\ would\ function\ like\ the\ new\ operator\ in\ languages\nlike\ C++\ or\ Java.\n\n======\n\ %\ set\ obj\ \[\[new\ MyClass\ inst1\]\n======\n\nThis\ sort\ of\ makes\ sense\ when\ you\ consider\ that\ Itcl\ provides\na\ delete\ method.\ In\ addition,\ if\ an\ object\ is\ only\ accessible\nvia\ the\ new\ command,\ one\ would\ have\ less\ worry\ of\ \"pollution\"\nof\ a\ namespace\ with\ lots\ of\ class\ constructor\ commands.\n\nItcl\ currently\ uses\ a\ model\ where\ the\ name\ of\ a\ class\ is\ a\ command\nthat\ invokes\ the\ constructor\ for\ a\ class.\ This\ is\ also\ the\ model\nused\ by\ Tk.\ To\ be\ perfectly\ blunt,\ it\ is\ just\ too\ late\ to\ change\nthe\ way\ Itcl\ objects\ are\ allocated.\ Even\ if\ Itcl\ was\ changed,\ it\ is\nfar\ too\ late\ to\ change\ Tk\ and\ object\ allocation\ in\ Itcl\ and\nTk\ need\ to\ be\ identical.\n\nWhile\ object\ construction\ is\ set\ in\ stone,\ the\ way\ objects\nshould\ be\ destroyed\ is\ not\ so\ clear.\ We\ need\ a\ solution\nthat\ provides\ a\ single\ way\ to\ destroy\ both\ Itcl\ and\ Tk\nobjects.\n\n'''Destruction\ Options:'''\n\n\ \ 1:\ delete\ instance\ command\n\n======\n\ \ %\ \$obj\ delete\n======\n\nThis\ was\ originally\ implemented\ in\ Itcl\ 1.X,\ it\ was\ later\ removed.\ It\ turns\ out\ that\ this\ conflicted\ badly\ with\ Tk\ widgets\ like\ Text,\ the\ already\ define\ a\ delete\ command.\n\n\ \ 2:\ delete\ command\n\n======\n\ \ %\ itcl::delete\ object\ \$obj\n======\n\nThis\ is\ the\ approach\ currently\ employed\ by\ Itcl.\ It\ is\ totally\ incompatible\ with\ the\ destruction\ semantics\ of\ Tk\ widgets.\ This\ alone\ is\ serious\ enough\ to\ warrant\ the\ removal\ of\ this\ command.\n\n\ \ 3:\ rename\ command\n\n======\n\ \ %\ rename\ \$obj\ \{\}\n======\n\nThis\ approach\ is\ also\ used\ in\ the\ current\ version\ of\ Itcl.\ This\ functionality\ can't\ be\ removed\ because\ it\ would\ break\ all\ sorts\ of\ Tk\ scripts.\ It\ should\ be\ replaced\ by\ something\ better\ and\ deprecated.\n\n\ \ 4:\ destroy\ command\n\n======\n\ \ %\ destroy\ \$obj\n======\n\nThis\ approach\ was\ used\ in\ early\ versions\ of\ Itcl.\ The\ problem\ was\ that\ the\ implementation\ was\ not\ transparent.\ The\ destroy\ command\ should\ be\ moved\ into\ Tcl\ in\ a\ way\ that\ makes\ it\ easy\ for\ Tk\ to\ simply\ extend\ the\ functionality\ to\ allow\ transparent\ destruction\ of\ Tk\ widgets.\ I\ will\ avoid\ the\ issue\ of\ raising/quashing\ exceptional\ conditions\ here.\n\nIncompatibility,\ duplicated\ functionality,\ and\ bears.\ Oh\ my!\n\n-\ How\ do\ Itcl\ features\ overlap\ or\ conflict\ with\ Tcl/Tk\ features\ ?\n\nIn\ this\ section\ we\ will\ explore\ how\ some\ Itcl\ features\ conflict,\ overlap,\ or\ fit\ in\ with\ features\ of\ the\ Tcl\ core.\n\n\ A\ -\ Declarations\n\ B\ -\ Class\ re-declaration\n\ C\ -\ Namespaces\n\ D\ -\ Access\ control\n\ E\ -\ Class\ procs\n\ F\ -\ Methods\n\ G\ -\ Option\ management\n\ H\ -\ Callbacks\ and\ access\ control\n\ I\ -\ Working\ around\ scope\ issues\n\ J\ -\ itcl::find\n\ K\ -\ The\ variable\ command\n\ L\ -\ Object\ aggregation\n\n'''A\ -\ Declarations'''\n\nTcl\ does\ not\ support\ the\ concept\ of\ declaring\ the\ way\ something\ should\ be\ used\ before\ it\ is\ used.\ Variables\ are\ set\ to\ a\ scalar,\ array\ type,\ or\ list\ type\ based\ on\ use.\ Procedures\ are\ defined\ at\ runtime,\nand\ are\ not\ declared.\ Tcl\ has\ no\ function\ prototypes.\nItcl\ adds\ the\ concept\ of\ classes\ that\ declare\ what\nfunctions\ they\ support.\ One\ can\ define\ commands\ninside\ a\ class\ definition\ (much\ like\ Java),\nbut\ it\ is\ often\ better\ to\ split\ the\ declaration\nand\ the\ implementation\ of\ class\ methods\ up.\nThis\ helps\ with\ readability\ and\ makes\ tracking\ndown\ syntax\ errors\ easier.\n\nItcl\ requires\ that\ you\ declare\ instance\ commands\n(methods)\ and\ class\ wide\ commands\ (class\ procs)\ndifferently,\ but\ it\ has\ no\ support\ for\ declaring\nthe\ type\ of\ a\ variable\ at\ class\ definition\ time.\n\nFor\ instance:\n\n======\n\ itcl::class\ Foo\ \{\n\ \ \ variable\ foo\n\ \}\n======\n\nBut\ not:\n\n======\n\ itcl::class\ Foo\ \{\n\ \ \ array\ variable\ foo\n\ \}\n======\n\n\n'''B\ -\ Class\ re-declaration'''\n\n\nA\ class\ can\ not\ be\ redefined.\ This\ directly\ncontradicts\ the\ semantics\ of\ variable\nand\ proc\ definitions.\ Some\ have\ suggested\nthat\ .h\ files\ are\ the\ best\ way\ to\ avoid\nany\ problems\ this\ causes.\ I\ frankly\ndon't\ see\ a\ need\ for\ the\ added\ complexity.\nRedefining\ a\ class\ should\ be\ the\ same\ as\ncalling\ \"itcl::delete\ class\ Foo\"\ and\ then\nrunning\ the\ class\ command\ again.\n\nThe\ argument\ has\ been\ made\ that\ this\ actually\nhelps\ programmers\ in\ the\ case\ where\ the\ same\nclass\ name\ is\ accidently\ used\ in\ two\ncompletely\ different\ files\ or\ modules.\nTcl\ has\ never\ provided\ this\ sort\ of\ \"help\".\nIn\ Tcl,\ the\ same\ proc\ or\ variable\ncan\ be\ created,\ deleted,\ or\ redefined\nin\ any\ file\ without\ having\ to\ worry\ that\nit\ had\ been\ defined\ elsewhere.\n\nThe\ most\ common\ way\ one\ would\ run\ into\nthis\ problem\ would\ be\ to\ source\ a\ file\nthat\ contained\ a\ class\ declaration\ntwice.\ The\ second\ time\ you\ run\n\[\[source\ foo.tcl\]\ an\ error\ would\nbe\ raised\ by\ the\ class\ command.\nThere\ is\ of\ course\ a\ trivial\noptimization\ one\ could\ employ\nhere.\ If\ a\ new\ class\ declaration\nis\ exactly\ the\ same\ as\ the\ old\none,\ simply\ do\ nothing.\n\n\n'''C\ -\ Namespaces'''\n\nItcl\ makes\ use\ of\ Tcl\ namespaces,\ but\ it\nalso\ adds\ additional\ features\ on\ top\non\ the\ existing\ namespace\ support\nprovided\ by\ Tcl.\ There\ is\ a\ long\nhistory\ of\ disagreement\ over\ the\nissue\ of\ access\ control\ and\ how\nit\ relates\ to\ namespaces.\n\n\ -\ Access\ control\ was\ not\ provided\ in\ Tcl\ 8.0\n\ -\ Ancestor\ based\ cmd/var\ lookup\ was\ not\ provided\ in\ Tcl\ 8.0\n\nIn\ Itcl\ 3.0,\ the\ ancestor\ based\ cmd/var\ lookup\nfeatures\ support\ was\ dropped.\ Access\ control\non\ the\ other\ hand,\ was\ retained.\n\nThe\ differences\ between\ namespaces\ and\ Itcl\nclasses\ is\ the\ cause\ of\ much\ confusion.\nI\ have\ also\ heard\ the\ opinion\ expressed\ that\nas\ soon\ as\ people\ have\ access\ to\ classes,\ they\nwill\ no\ longer\ need\ to\ worry\ about\ namespaces.\n\nThis\ \"solution\"\ to\ the\ problem\ of\ incompatibilities\nbetween\ Itcl\ and\ Tcl\ is\ not\ much\ help.\ Either\nTcl\ namespaces\ need\ to\ be\ changed\ so\ that\nthey\ provide\ functionality\ that\ Itcl\ requires\nor\ Itcl\ will\ need\ to\ be\ modified\ to\ require\nonly\ the\ functionality\ that\ Tcl\ namespace\nprovide.\ If\ people\ are\ having\ trouble\ seeing\nhow\ namespaces\ and\ classes\ fit\ together,\nperhaps\ it\ is\ because\ they\ do\ not.\ We\nneed\ to\ address\ the\ issue\ and\ not\ gloss\nover\ it\ with\ \"quick\ fixes\".\n\n\n'''D\ -\ Access\ Control'''\n\nTcl\ provides\ no\ support\ for\ access\ control.\ Both\nvariables\ and\ procedures\ can\ be\ freely\ modified\nby\ any\ part\ of\ a\ Tcl\ program.\ There\ tend\ to\ be\na\ couple\ reasons\ to\ put\ access\ controls\ on\ variables\nand\ procedures.\ One\ reason\ is\ to\ stop\ programmers\nfrom\ accidently\ accessing\ a\ method\ or\ data.\ If\ two\ndifferent\ modules\ accidently\ used\ the\ same\ global\nvariable,\ the\ result\ could\ be\ a\ disaster.\ Access\ncontrol\ also\ plays\ a\ documentation\ role.\ If\ a\nvariable\ or\ method\ is\ declared\ \"private\",\ that\nwould\ provide\ a\ very\ good\ hint\ that\ the\ author\ndid\ not\ want\ you\ to\ use\ that\ function\ from\ outside\nthe\ given\ class.\ Not\ being\ able\ to\ call\ a\ private\nmethod\ from\ the\ public\ instance\ handle\ is\ a\ good\nclue\ that\ you\ not\ meant\ to\ use\ it.\ Itcl's\ access\ncontrol\ policy\ does\ make\ it\ harder\ to\ get\naccess\ to\ private\ data,\ but\ it\ does\ not\ actually\nstop\ anyone\ from\ reading\ or\ writing\ variables\ or\ncalling\ private\ methods\ from\ outside\ of\ the\ class\ scope.\n\nAccess\ control\ is\ currently\ in\ a\ \"half\ and\ half\"\ state.\nTcl\ namespaces\ do\ not\ implement\ any\ sort\ of\ access\ncontrol.\ Itcl\ tries\ to\ layer\ its\ own\ notions\ of\naccess\ control\ on\ top\ of\ Tcl\ namespaces,\ which\ncauses\ some\ problems.\n\n\n======\n\ itcl::class\ DontCallMe\ \{\n\ \ \ \ private\ proc\ argh\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \$msg\n\ \ \ \ \}\n\n\ \ \ \ private\ common\ msg\ \"ARRRAGH!\"\n\ \}\n\n\ %\ namespace\ eval\ DontCallMe\ \{argh\}\n\ ARRRAGH!\n\n\ %\ set\ DontCallMe::msg\ \"WOHOOO!!\"\n\n\ %\ namespace\ eval\ DontCallMe\ \{argh\}\n\ WOHOOO!!\n======\n\n\nNote\ how\ in\ the\ above\ example,\ we\ncan\ directly\ set\ a\ private\ class\nvariable\ and\ we\ can\ call\na\ private\ method\ by\ simply\ adding\na\ namespace\ eval.\ In\ fact,\ this\nis\ exactly\ what\ the\ itcl::code\nmethod\ does.\n\nLet's\ face\ it,\ control\ is\ complex!\nMisuse\ of\ access\ control\ can\ easily\nlead\ to\ some\ really\ tricky\ bugs.\n\nIn\ this\ example\ we\ see\ how\nItcl's\ existing\ access\ control\nfeatures\ can\ be\ misused\ in\na\ way\ that\ breaks\ perfectly\ngood\ code.\ One\ can\ redefine\nsubclass\ method\ access\nin\ a\ way\ that\ break\ the\nAPI\ of\ the\ parent\ class\nwith\ respect\ to\ an\ isa\ test.\n\n\n======\n\ itcl::class\ Base\ \{\n\ \ \ \ public\ method\ doit\ \{\}\ \{\n\ \ \ \ \ \ \ \ return\ XJ45.1\n\ \ \ \ \}\n\ \}\n\n\n\ proc\ print_base\ \{\ base\ \}\ \{\n\ \ if\ \{\[\[\$base\ isa\ Base\]\}\ \{\n\ \ \ \ \ \ puts\ \"!!!!!\ \[\[\$base\ doit\]\ !!!!\"\n\ \ \}\ else\ \{\n\ \ \ \ \ \ puts\ \"not\ derived\ from\ Base\"\n\ \ \}\n\ \}\n\n\n\ %\ Base\ b\n\ %\ print_base\ b\n\ !!!!!\ XJ45.1\ !!!!\n======\n\n\nAnd\ now\ for\ a\ subclass:\n\n======\n\ itcl::class\ Derived\ \{\n\ \ \ \ inherit\ Base\n\n\ \ \ \ private\ method\ doit\ \{\}\ \{\n\ \ \ \ \ \ \ \ return\ XJ45.2\n\ \ \ \ \}\n\ \}\n\n\ %\ Derived\ d\n\ %\ print_base\ d\n\ bad\ option\ \"doit\":\ should\ be\ one\ of...\n\ \ d\ cget\ -option\n\ \ d\ configure\ ?-option?\ ?value\ -option\ value...?\n\ \ d\ isa\ className\n======\n\n\nThis\ example\ shows\ how\ one\ can\ break\nthe\ isa\ relationship\ by\ misusing\naccess\ controls.\n\n\n'''E\ -\ Class\ procs'''\n\nThese\ sorts\ of\ procs\ are\ defined\ with\ the\ itcl::body\ command.\nThey\ are\ subtly\ different\ than\ regular\ Tcl\ procs.\ For\ instance,\nin\ a\ class\ proc\ variables\ defined\ as\ common\ are\ accessible\ by\ndefault.\ A\ regular\ Tcl\ proc\ only\ has\ access\ to\ local\ variables\nby\ default.\ Procs\ defined\ with\ the\ body\ command\ also\ make\nuse\ of\ access\ control,\ regular\ Tcl\ procs\ have\ no\ access\nprotection.\n\n\nAt\ first\ glance,\ these\ two\ bits\ of\ code\ might\nseem\ like\ they\ do\ the\ same\ things:\n\n======\n\ namespace\ eval\ Two\ \{\n\ \ \ \ proc\ gak\ \{\ \}\ \{\n\ \ \ \ \ \ return\ GAK2\n\ \ \ \ \}\n\ \}\n\n\ %\ Two::gak\n\ GAK1\n\n\ itcl::class\ One\ \{\n\ \ \ \ proc\ gak\ \{\ \}\ \{\n\ \ \ \ \ \ return\ GAK1\n\ \ \ \ \}\n\ \}\n\n\ %\ One::gak\n\ GAK2\n======\n\nBut,\ when\ you\ introduce\ a\ variable\ninto\ the\ mix,\ the\ difference\ shows.\n\n======\n\ namespace\ eval\ Two\ \{\n\ \ \ \ variable\ result\ GAK1\n\n\ \ \ \ proc\ gak\ \{\ \}\ \{\n\ \ \ \ \ \ return\ \$result\n\ \ \ \ \}\n\ \}\n\n\ %\ Two::gak\n\ can't\ read\ \"result\":\ no\ such\ variable\n\n\ itcl::class\ One\ \{\n\ \ \ \ common\ result\ GAK1\n\n\ \ \ \ proc\ gak\ \{\ \}\ \{\n\ \ \ \ \ \ return\ \$result\n\ \ \ \ \}\n\ \}\n\n\ %\ One::gak\n\ GAK2\n======\n\nOne\ needs\ to\ explicitly\ make\ a\ namespace\nvariable\ visible\ to\ a\ regular\ Tcl\ proc\ndefined\ in\ a\ namespace.\n\n\n======\n\ namespace\ eval\ Two\ \{\n\ \ \ \ variable\ result\ GAK2\n\n\ \ \ \ proc\ gak\ \{\ \}\ \{\n\ \ \ \ \ \ variable\ result\n\ \ \ \ \ \ return\ \$result\n\ \ \ \ \}\n\ \}\n\n\ %\ Two::gak\n\ GAK2\n======\n\n\nThe\ new\ \"class\ proc\"\ type\ also\nmakes\ it\ impossible\ to\ declare\na\ regular\ proc\ in\ a\ class\ndefinition.\ One\ would\ need\ to\nsurround\ a\ proc\ definition\nwith\ a\ \[\[namespace\ eval\]\ to\nget\ a\ similar\ effect.\n\nThe\ whole\ concept\ of\ a\n\"class\ proc\"\ is\ in\ conflict\nwith\ the\ behavior\ and\nmethod\ of\ declaration\ of\nregular\ Tcl\ procs.\n\nThere\ is\ also\ reason\ to\nbe\ concerned\ about\ the\nway\ itcl::body\ duplicates\nfunctionality\ seemingly\ncovered\ by\ the\ proc\ command.\nTcl\ has\ always\ had\ one\nway\ of\ declaring\ a\ proc,\nwith\ the\ proc\ command.\nWe\ need\ to\ think\ long\ and\nhard\ about\ our\ options\nbefore\ changing\ that.\n\n\n\n'''F\ -\ Methods'''\n\nInstance\ methods\ are\ the\ second\ type\nof\ new\ command\ added\ by\ Itcl.\ Methods\nare\ different\ than\ regular\ procs,\nsince\ they\ can\ only\ be\ invoked\ on\na\ valid\ object\ instance.\n\nHere\ is\ a\ quick\ example\ of\ how\nthey\ are\ currently\ defined\ using\nitcl::body.\n\n======\n\ itcl::class\ Example\ \{\n\ \ \ \ private\ proc\ foo\ \{\}\n\ \ \ \ private\ method\ bar\ \{\}\n\ \}\n\n\ itcl::body\ Example::foo\ \{\}\ \{\n\ \ \ \ puts\ \"called\ foo\"\n\ \}\n\n\ itcl::body\ Example::bar\ \{\}\ \{\n\ \ \ \ puts\ \"called\"\n\ \}\n======\n\n\nMethods\ are\ not\ really\ incompatible\nwith\ anything\ in\ Tcl,\ but\ the\ way\nthey\ are\ defined\ is.\n\nTcl\ has\ always\ used\ the\ proc\ command\nfor\ this\ sort\ of\ thing.\ We\ need\ to\nbe\ absolutely\ sure\ that\ adding\ a\ntoplevel\ \"body\"\ command\ to\ Tcl\ is\nreally\ the\ optimal\ solution.\ I\ am\nnot\ convinced\ that\ it\ is.\n\n\n\n'''G\ -\ Option\ management'''\n\nItcl's\ concept\ of\ configurable\ options\ is\ntightly\ coupled\ with\ \"public\ variables\".\nThese\ public\ variables\ can\ be\ declared\nonly\ when\ the\ class\ is\ created.\nThis\ approach\ works\ well\ for\ simple\ cases,\nbut\ it\ fails\ to\ meet\ the\ needs\ of\ more\ncomplex\ applications.\n\nEvidence\ of\ this\ can\ be\ found\ in\ itk,\ the\nmega-widget\ based\ framework\ build\ on\ top\nof\ Itcl.\ Instead\ of\ using\ itcl\ style\npublic\ variables,\ Itk\ stores\ object\nconfiguration\ options\ in\ an\ array\nnamed\ itk_option.\n\nThis\ make\ it\ possible\ to\ add\ an\ option\ninside\ an\ object's\ constructor,\ something\nthat\ you\ simply\ can't\ do\ in\ Itcl.\ The\ fact\nthat\ Itk\ uses\ its\ own\ option\ configuration\nsystem\ can\ lead\ to\ some\ serious\ problems\ when\nmixing\ Itcl\ and\ Itk\ based\ objects.\n\nHere\ is\ a\ quick\ example:\n\n======\n\ itcl::class\ Foo\ \{\n\ \ \ \ inherit\ itk::Widget\n\n\ \ \ \ public\ variable\ myoption\ off\n\ \}\n\n\ %\ Foo\ .f\n\ %\ .f\ cget\ -myoption\n\ unknown\ option\ \"-myoption\"\n======\n\nConfused?\ You\ should\ be.\n\nThis\ error\ is\ a\ side\ effect\ of\ itk's\ implementation.\nItk\ replaces\ Itcl's\ public\ variable\ based\ option\nconfiguration,\ and\ rightly\ so.\ An\ option\ system\nthat\ is\ statically\ defined\ at\ class\ declaration\ntime\ is\ at\ odds\ with\ the\ dynamic\ needs\ of\nmega-widget\ systems.\n\nOptions\ also\ have\ their\ own\ special\ sort\ of\ncallbacks,\ and\ a\ special\ way\ to\ define\nthese\ callbacks.\n\nThe\ itcl::configbody\ command\ supports\ a\ sort\nof\ inlined\ trace\ method\ that\ in\ run\ninside\ the\ scope\ of\ an\ instance\ when\nan\ option\ is\ configured.\ When\ a\ user\ runs\n\n======\n\ %\ \$obj\ configure\ -foo\ bar\n======\n\na\ configbody\ callback\ for\ the\ -foo\ option\nis\ called.\ The\ configbody\ is\ a\ bit\ of\ a\nstrange\ mix\ between\ a\ variable\ trace\nand\ an\ instance\ method.\n\nIt\ can\ be\ handy,\ but\ it\ also\ adds\ an\nadditionally\ layer\ of\ functionality\nthat\ could\ be\ implemented\ without\nthe\ need\ to\ introduce\ a\ new\nglobal\ \"configbody\"\ command.\n\nThe\ configbody\ command\ also\ has\ a\nmajor\ shortcoming.\ The\ configbody\ncommand\ is\ like\ a\ write\ trace,\ but\nthere\ is\ no\ support\ for\ a\ read\ntrace\ on\ an\ option.\ This\ is\ a\nserious\ problem,\ you\ can\ work\ around\nit\ but\ it\ is\ not\ easy\ or\ fun.\n\nIt\ is\ just\ not\ clear\ that\ the\nfunctionality\ provided\ by\ the\nconfigbody\ command\ is\ important\nenough\ to\ require\ the\ addition\nof\ a\ global\ Tcl\ command\ for\ it.\n\n'''H\ -\ Callbacks\ and\ access\ control'''\n\nThe\ itcl::code\ command\ provides\ a\nway\ to\ bypass\ access\ control\nfor\ Itcl\ procs\ and\ methods.\n\nExample:\n\n======\nset\ cmd\ \"\"\n\nitcl::class\ Example\ \{\n\ \ \ \ constructor\ \{\}\ \{\n\ \ \ \ \ \ \ \ global\ cmd\n\ \ \ \ \ \ \ \ set\ cmd\ \[\[itcl::code\ \$this\ foo\]\n\ \ \ \ \}\n\n\ \ \ \ private\ method\ foo\ \{\}\ \{\n\ \ \ \ \ \ \ \ puts\ \"called\ foo\ for\ \$this\"\n\ \ \ \ \}\n\}\n\n%\ Example\ e1\ne1\n\n#\ Run\ the\ callback\ saved\ in\ \$cmd\n%\ eval\ \$cmd\ncalled\ foo\ for\ ::e1\n======\n\nThe\ itcl::code\ command\ works\ by\ncreating\ a\ \"backdoor\"\ into\nthe\ Example\ namespace,\ like\ so:\n\n======\n%\ set\ cmd\nnamespace\ inscope\ ::Example\ \{::e1\ foo\}\n======\n\nOf\ course,\ the\ constructor\ for\nthe\ Example\ class\ could\ have\nbeen\ coded\ without\ the\ itcl::code\nmethod,\ but\ it\ would\ have\ been\nslightly\ uglier:\n\n======\n\ \ \ \ constructor\ \{\}\ \{\n\ \ \ \ \ \ \ \ global\ cmd\n\ \ \ \ \ \ \ \ set\ cmd\ \[\[namespace\ inscope\ \\\n\ \ \ \ \ \ \ \ \ \ \ \ \[\[namespace\ current\]\ \[\[list\ \$this\ foo\]\]\n\ \ \ \ \}\n======\n\n'''I\ -\ Working\ around\ scope\ issues'''\n\nThe\ itcl::scope\ command\ provides\ a\n\"backdoor\"\ for\ variable\ scope.\ There\ is\nno\ access\ control\ for\ variables.\ You\ncan\ always\ set\ a\ variable\ as\ long\ as\nyou\ know\ the\ full\ scope\ of\ the\ variable\nname.\ The\ itcl::scope\ command\ provides\na\ handy\ way\ to\ get\ this\ info.\n\nThe\ ability\ to\ access\ instance\nvariables\ using\ the\ scope\ command\nwas\ added\ for\ Itcl\ 3.0.\ This\nis\ an\ incredibly\ useful\ feature,\nespecially\ for\ Tk\ GUIs.\ Older\nversions\ of\ Itcl\ required\ the\nsame\ global\ array\ indexing\nhacks\ that\ are\ blamed\ for\ the\npoor\ performance\ and\ readability\nof\ tcllib.\n\n\nA\ quick\ example:\n\n======\nset\ var\ \"\"\n\nitcl::class\ Example\ \{\n\ \ \ \ constructor\ \{\}\ \{\n\ \ \ \ \ \ \ \ global\ var\n\ \ \ \ \ \ \ \ set\ var\ \[\[itcl::scope\ _name\]\n\ \ \ \ \}\n\n\ \ \ \ private\ variable\ _name\ \"bob\"\n\}\n======\n\n\nNote\ that\ unlike\ the\ itcl::code\ncommand,\ the\ itcl::scope\ command\ndoes\ not\ require\ that\ you\ pass\ the\nname\ of\ instance\ variable\ \$this.\n\n======\n%\ Example\ e1\ne1\n\n%\ set\ \[\[set\ var\]\nbob\n======\n\nThis\ works\ because\ itcl::scope\ lets\nus\ bypass\ any\ access\ protection\nand\ directly\ access\ the\ instance\ var.\n\n\nHere\ is\ how\ it\ is\ implemented:\n\n======\n%\ set\ var\n@itcl\ ::e1\ ::Example::_name\n======\n\nThe\ above\ list\ may\ not\ look\ like\ other\nTcl\ variable\ names,\ it\ is\ not.\ It\nis\ a\ special\ form\ of\ a\ variable\ name\nknown\ only\ to\ Itcl.\ Itcl\ uses\ a\ C\ API\nto\ register\ a\ custom\ variable\ name\nresolver\ when\ it\ is\ loaded\ into\ Tcl.\n\nThe\ issue\ with\ scoping\ is\ not\ so\ much\nan\ incompatibility\ with\ Tcl\ as\ much\ as\ it\ is\na\ new\ feature\ that\ the\ core\ may\ need\ to\nsupport\ directly.\ One\ possible\ modification\nwould\ be\ to\ use\ a\ separator\ other\ than\ space\nin\ the\ variable\ name.\ There\ will\ be\ code\nthat\ assumes\ variable\ names\ do\ not\ have\nspaces\ in\ them,\ for\ instance\ when\ a\ var\ name\nis\ passed\ to\ an\ eval.\ I\ assume\ that\ a\ toplevel\nscope\ command\ would\ be\ created,\ but\ there\ are\ncertainly\ other\ options\ if\ avoiding\ namespace\npollution\ is\ a\ big\ issue.\n\n'''J\ -\ itcl::find\ command'''\n\nThe\ itcl::find\ command\ was\ originally\ incorporated\ninto\ the\ info\ command.\ It\ should\ be\ put\ back.\nThere\ is\ no\ justification\ for\ adding\ a\ toplevel\nfind\ command\ just\ to\ support\ searching\ for\ objects.\n\nIt\ might\ also\ be\ useful\ to\ look\ into\ adding\ a\nway\ to\ determine\ if\ an\ object\ exists\ without\nhaving\ to\ compare\ to\ a\ named\ object\ result.\nThis\ would\ make\ the\ users\ life\ easier\ and\nwould\ surely\ execute\ more\ quickly\ than\nthe\ current\ solution.\ It\ would\ be\ like\nthe\ winfo\ exists\ command,\ but\ for\ objects.\n\n\n\n'''K\ -\ The\ variable\ command'''\n\nItcl's\ variable\ command\ is\ in\ conflict\nwith\ Tcl's\ variable\ command.\ In\ fact,\nthey\ are\ almost\ exact\ opposites.\n\nHere\ is\ a\ quick\ example.\n\n======\n\ namespace\ eval\ One\ \{\n\ \ \ \ variable\ Number\ 1\n\ \}\n\n\ %\ set\ One::Number\n\ 1\n\n\n\ itcl::class\ Two\ \{\n\ \ \ \ variable\ Number\ 2\n\ \}\n\n\ %\ set\ Two::Number\n\ can't\ read\ \"Two::Number\":\ no\ such\ variable\n======\n\n\nWhy\ ,you\ ask?\n\nItcl\ uses\ the\ variable\ command\ to\ndefine\ an\ instance\ variable.\ Tcl\nuses\ the\ variable\ command\ to\ declare\na\ namespace\ variable,\ similar\ to\na\ common\ variable\ in\ Itcl.\n\nlike\ so:\n\n======\n\ itcl::class\ Two\ \{\n\ \ \ \ common\ Number\ 2\n\ \}\n\n\ %\ set\ Two::Number\n\ 2\n======\n\n\nI\ personally\ find\ the\ common\ command\na\ bit\ confusing.\ It\ does\ not\ make\ it\nparticularly\ obvious\ that\ the\ thing\nbeing\ declared\ is\ a\ variable.\ When\nyou\ combine\ common\ with\ and\ inlined\nvariable\ initialization\ and\ an\ninlined\ configbody\ callback,\ the\nresult\ can\ end\ up\ looking\ a\ lot\nlike\ a\ method\ declaration.\n\n======\n\ itcl::class\ Two\ \{\n\ \ \ \ common\ Number\ \{one\ two\}\ \{\n\ \ \ \ \ \ puts\ \"called\ me\"\n\ \ \ \ \}\n\ \}\n======\n\n'''L\ -\ Object\ aggregation'''\n\nItcl\ has\ no\ built-in\ support\ for\nobject\ aggregation!\ It\ is\ really\ quite\nbaffling.\ Object\ aggregation\ is\ an\nincredibly\ useful\ concept\ and\ it\nis\ well\ supported\ in\ languages\nlike\ C++\ and\ Java.\n\n\nHere\ is\ a\ quick\ example:\n(C++)\n\n======c++\n\ class\ Member1\ \{\}\;\n\ class\ Member2\ \{\}\;\n\n\ class\ Aggregate\ \{\n\ \ Member1\ mem1\;\n\ \ Member2\ mem2\;\n\ \}\;\n\n\ (Java)\n\n\ class\ Member1\ \{\}\n\ class\ Member2\ \{\}\n\n\ class\ Aggregate\ \{\n\ \ Member1\ mem1\ =\ new\ Member1()\;\n\ \ Member2\ mem2\ =\ new\ Member2()\;\n\ \}\n======\n\n\nTo\ do\ this\ same\ thing\ in\ Itcl,\nthe\ programmer\ needs\ to\ allocate\nand\ free\ the\ objects\ by\ hand.\n\n======\n\ itcl::class\ Member1\ \{\}\n\ itcl::class\ Member2\ \{\}\n\n\ itcl::class\ Aggregate\ \{\n\ \ variable\ mem1\n\ \ variable\ mem2\n\n\ \ constructor\ \{\ \}\ \{\n\ \ \ \ set\ mem1\ \[\[Member1\ \$\{this\}_mem1\]\n\ \ \ \ set\ mem2\ \[\[Member2\ \$\{this\}_mem2\]\n\ \ \}\n\n\ \ destructor\ \{\n\ \ \ \ itcl::delete\ object\ \$mem1\ \$mem2\n\ \ \}\n\ \}\n======\n\n\n'''Layers\ of\ Change'''\n\nNow\ for\ the\ fun\ stuff!\ In\ this\ section\ I\npresent\ some\ suggested\ changes\ to\ better\nintegrate\ Itcl\ into\ the\ Tcl\ core.\ Each\nlayer\ suggests\ more\ comprehensive\ changes\nthan\ the\ previous\ one,\ and\ some\ changes\nbuild\ upon\ the\ previous\ layer.\n\nThese\ suggestions\ assume\ that\ backwards\ncompatibility\ would\ be\ dealt\ with\ using\na\ loadable\ package\ that\ would\ wrap\ around\nthe\ new\ implementation.\n\n'''Layer\ 0:'''\nNo\ changes!\n\nThis\ approach\ would\ simply\ move\ all\ the\ Itcl\ commands\ into\ the\ global\ namespace.\ This\ is\ an\ all\ or\ nothing\ approach.\ It\ is\ not\ going\ to\ be\ possible\ to\ move\ some\ Itcl\ commands\ into\ the\ global\ namespace\ and\ leave\ some\ in\ the\ itcl\ namespace.\ That\ would\ only\ serve\ to\ break\ the\ scripts\ of\ folks\ that\ run\ \[\[namespace\ import\ itcl::*\].\ Still,\ not\ everyone\ is\ going\ to\ be\ happy.\ There\ will\ be\ folks\ that\ use\ the\ itcl::\ prefix\ for\ method\ invocations,\ those\ scripts\ will\ be\ broken\ by\ this\ approach.\n\nThe\ \"no\ changes\"\ approach\ would\ most\ benefit\ those\ who\ already\ have\ large\ applications\ written\ in\ Itcl.\ The\ benefit\ being\ they\ would\ not\ need\ to\ rewrite\ an\ application\ that\ was\ written\ to\ the\ Itcl\ 3.0\ API.\n\nIf\ the\ application\ used\ any\ older\ 1.X\ or\ 2.X\ APIs\ that\ are\ still\ supported\ in\ Itcl\ 3.0,\ it\ would\ not\ work\ with\ the\ new\ integrate\ OO\ system.\ Solving\ that\ legacy\ code\ problem\ would\ mean\ introducing\ even\ more\ toplevel\ command\ like\ itcl_class\ and\ so\ on.\ It\ is\ a\ slippery\ slope,\ we\ need\ to\ cleanly\ integrate\ Itcl\ 3.X,\ and\ use\ add\ on\ packages\ for\ backwards\ compatibility.\ It\ seems\ obvious\ that\ the\ best\ people\ to\ implement\ such\ a\ wrapper\ would\ be\ those\ folks\ with\ a\ vested\ interest\ in\ getting\ legacy\ code\ running\ on\ the\ OO\ enabled\ Tcl\ core.\n\nSome\ folks\ contend\ that\ Layer\ 0\ is\ the\ only\ valid\ option.\ They\ claim\ that\ any\ syntactic\ or\ semantic\ change\ will\ alienate\ current\ Itcl\ users.\ While\ this\ is\ a\ concern,\ it\ is\ not\ predominant.\n\n\n'''Layer\ 1:'''\nChanges\ that\ are\ not\ likely\ to\ cause\ incompatibilities\ and\ will\ fix\ real\ problems\ or\ simply\ remove\ obsolete\ code.\n\n1.1\ Constructors\ must\ return\ fully\ qualified\ names:\n\n\ \ \ *\ This\ would\ fix\ a\ number\ of\ problems\ related\ to\ passing\ objects\ from\ namespace\ to\ namespace.\n\ \ \ *\ This\ would\ remove\ the\ need\ to\ itk_component(hull)\ in\ itk\ code.\n\ \ \ *\ A\ small\ change\ to\ Tk\ would\ be\ required\ to\ implement\ this\ properly.\ Fetching\ a\ window\ name\ would\ implicitly\ do\ a\ \[\[namespace\ tail\ \$w\]\].\n\n1.2\ Remove\ class\ autoloading\n\n\ \ \ *\ This\ is\ obsolete\ code,\ it\ was\ only\ left\ in\ Itcl\ 3\ for\ backwards\ compatibility\ reasons.\n\n1.3\ Disallow\ dynamic\ method\ invocation\ in\ constructor\n\nThe\ problem\ is\ described\ here:\n\n\ \ \ \ \ http://dev.scriptics.com/lists/itcl/2000/11/msg00031.html\ (Link\ is\ dead.\ No\ replacement\ found\ yet)\n\nThe\ solution\ is\ to\ simply\ not\ allow\ it.\n\n1.4\ Disallow\ dangerous\ method\ protection\ changes\n\nThe\ problem\ is\ described\ in\ incompatibilities\ section\ D.\ Changes\ that\ break\ an\ object's\ isa\ relationship\ should\ not\ be\ allowed.\n\n1.5\ Allow\ redefinition\ of\ classes\n\nThe\ class\ command\ should\ not\ raise\ an\ error\ when\ duplicate\ class\ is\ encountered.\ If\ the\ class\ declaration\ has\ changed,\ the\ system\ should\ call\ \[\[itcl::delete\ class\ \$class\]\ and\ then\ redefine\ it.\ In\ the\ trivial\ case\ where\ the\ exact\ same\ declaration\ body\ is\ twice,\ the\ second\ declaration\ can\ simply\ be\ ignored.\ We\ should\ not\ force\ Tcl\ programmers\ into\ a\ C/C++\ style\ model\ where\ .h\ file\ are\ the\ norm.\n\n\n'''Layer\ 2:'''\nIncorporation\ of\ Itcl\ functionality\ into\ existing\ Tcl\ commands.\n\n2.1\ proc\ command\ can\ replace\ the\ body\ command\n\nThis\ will\ address\ incompatibilities\ discussed\ in\ sections\ E\ and\ F.\ The\ existing\ class\ declaration\ syntax\ would\ still\ be\ used,\ but\ the\ proc\ command\ would\ be\ substituted\ for\ the\ itcl::body\ command.\n\n======\n\ \ \ \ \ class\ Example\ \{\n\ \ \ \ \ \ \ proc\ foo\ \{\}\n\ \ \ \ \ \ \ method\ bar\ \{\}\n\ \ \ \ \ \}\n\n\ \ \ \ \ proc\ Example::foo\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ foo\"\n\ \ \ \ \ \}\n\n\ \ \ \ \ proc\ Example::bar\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ bar\"\n\ \ \ \ \ \}\n======\n\nThis\ approach\ would\ mean\ that\ the\ itcl::body\ command\ would\ not\ longer\ be\ needed.\n\n2.2\ \[\[info\ objects\]\ instead\ of\ itcl::find\n\nThis\ was\ discussed\ in\ section\ J,\ itcl::find\ is\ simply\ not\ useful\ enough\ \ to\ deserve\ its\ own\ global\ command.\ The\ functionality\ of\ find\ should\ be\ incorporated\ into\ the\ info\ command.\n\n\n'''Layer\ 3:'''\nChanges\ to\ the\ object\ declaration\ syntax\ (but\ not\ semantics)\ of\ classes.\n\nIn\ this\ section,\ we\ explore\ the\ impact\ of\ adding\ an\ \"instance\"\ modifier\ to\ the\ class\ declaration\ syntax.\ This\ addresses\ two\ issues.\ The\ first\ the\ variable\ command,\ as\ described\ in\ section\ K.\ The\ second\ is\ an\ objection\ to\ using\ proc\ instead\ of\ body,\ as\ described\ in\ Layer\ 2.\ Some\ folks\ felt\ that\ using\ the\ proc\ command\ to\ define\ the\ body\ of\ a\ \"method\"\ could\ be\ confusing.\n\n3.1\ instance\ modifier\n\nFor\ variables:\n\n======\n\ \ \ \ \ class\ Example\ \{\n\ \ \ \ \ \ \ instance\ variable\ _name\ \"bob\"\n\ \ \ \ \ \ \ variable\ _total\ 0\n\ \ \ \ \ \}\n======\n\nInstead\ of:\n\n======\n\ \ \ \ \ itcl::class\ Example\ \{\n\ \ \ \ \ \ \ variable\ _name\ \"bob\"\n\ \ \ \ \ \ \ common\ _total\ 0\n\ \ \ \ \ \}\n======\n\nFor\ methods:\n\n======\n\ \ \ \ \ class\ Example\ \{\n\ \ \ \ \ \ \ proc\ foo\ \{\}\n\ \ \ \ \ \ \ instance\ proc\ bar\ \{\}\n\ \ \ \ \ \}\n\n\ \ \ \ \ proc\ Example::foo\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ foo\"\n\ \ \ \ \ \}\n\n\ \ \ \ \ proc\ Example::bar\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ bar\"\n\ \ \ \ \ \}\n======\n\nInstead\ of:\n\n======\n\ \ \ \ \ itcl::class\ Example\ \{\n\ \ \ \ \ \ \ proc\ foo\ \{\}\n\ \ \ \ \ \ \ method\ bar\ \{\}\n\ \ \ \ \ \}\n\n\ \ \ \ \ itcl::body\ Example::foo\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ foo\"\n\ \ \ \ \ \}\n\n\ \ \ \ \ itcl::body\ Example::bar\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ bar\"\n\ \ \ \ \ \}\n======\n\nThis\ approach\ would\ solve\ the\ problem\ of\ incompatible\ variable\ commands.\ Using\ an\ \"instance\"\ modifier\ would\ mean\ that\ \"common\"\ and\ \"method\"\ would\ no\ longer\ be\ needed.\ That\ is\ a\ good\ thing\ in\ my\ book,\ \"instance\ variable\"\ is\ a\ lot\ more\ descriptive\ than\ \"common\".\n\n\n'''Layer\ 4:'''\nSemantic\ changes\ that\ would\ require\ some\ rewriting\ of\ effected\ code.\n\n\ \ \ 4.1\ Get\ rid\ of\ class\ procs\n\nMany\ of\ the\ problems\ mapping\ Itcl\ classes\ to\ Tcl\ namespaces\ seem\ to\ be\ related\ to\ class\ procs.\ Class\ procs\ are\ also\ cited\ as\ a\ reason\ that\ the\ proc\ command\ can\ not\ be\ used\ instead\ of\ the\ body\ command.\n\nWhen\ you\ get\ right\ down\ to\ it,\ class\ procs\ are\ simply\ incompatible\ with\ Tcl\ procs.\ They\ have\ different\ variable\ access\ defaults\ and\ class\ procs\ employ\ access\ control.\ Why\ should\ there\ be\ a\ distinction\ between\ procs\ defined\ in\ a\ namespace\ vs\ procs\ defined\ in\ a\ class\ body?\n\nI\ suggest\ the\ removal\ of\ the\ entire\ concept\ of\ class\ procs.\ Programmers\ would\ need\ to\ explicitly\ import\ namespace\ variables\ and\ there\ would\ be\ no\ access\ control,\ but\ Tcl\ programmers\ have\ been\ dealing\ with\ these\ issues\ for\ a\ long\ time.\ The\ benefit\ would\ be\ a\ significant\ simplification\ of\ the\ implementation,\ since\ folks\ would\ be\ using\ regular\ Tcl\ procs.\n\n'''Layer\ 5:'''\nLarge\ changes\ that\ would\ modify\ both\ the\ semantics\ and\ syntax\ of\ object\ use.\ These\ changes\ would\ not\ be\ backward\ compatible\ by\ any\ stretch\ of\ the\ imagination.\n\n5.1\ Don't\ use\ public\ variables\ as\ options!\n\nThe\ use\ of\ public\ variables\ as\ the\ means\ to\ specify\ object\ options\ was\ a\ mistake.\ Itk's\ custom\ option\ system\ is\ proof\ that\ Itcl\ declaration\ based\ option\ system\ does\ not\ scale\ well.\ There\ is\ no\ reason\ to\ re-invent\ the\ wheel\ here,\ we\ can\ simply\ add\ itk's\ option\ interface\ directly\ to\ Tcl.\ \ \ This\ solves\ many\ of\ the\ issues\ described\ in\ section\ G.\n\nThe\ first\ problem,\ is\ of\ course\ the\ command\ and\ variable\ names\ used\ by\ itk.\ One\ possible\ approach\ would\ be\ to\ use\ \"oo_option\"\ instead\ of\ \"itk_option\".\n\n======\n\ \ \ \ \ class\ HiThere\ \{\n\n\ \ \ \ \ \ \ oo_option\ define\ -command\ \{puts\ \"hi\"\}\n\n\ \ \ \ \ \ \ constructor\ \{\ args\ \}\ \{\n\ \ \ \ \ \ \ \ \ oo_option\ initialize\ \$args\n\n\ \ \ \ \ \ \ \ \ puts\ \"-command\ is\ \$oo_option(-command)\"\n\ \ \ \ \ \ \ \}\n\ \ \ \ \ \}\n======\n\nThis\ approach\ to\ option\ management\ would\ also\ remove\ the\ need\ for\ a\ itcl::body\ command.\ A\ configbody\ callback\ is\ really\ like\ a\ variable\ trace,\ why\ don't\ we\ leverage\ that?\ It\ would\ also\ be\ trivial\ to\ add\ support\ for\ read\ traces.\n\n======\n\ \ \ \ \ class\ HiThere\ \{\n\n\ \ \ \ \ \ \ oo_option\ define\ -command\ \{puts\ \"hi\"\}\n\n\ \ \ \ \ \ \ oo_option\ trace\ w\ -command\ \{\n\ \ \ \ \ \ \ \ \ \ \ puts\ \"wrote\ -command\ value\ is\ \\\"\$oo_option(-command)\\\"\"\n\ \ \ \ \ \ \ \}\n\n\ \ \ \ \ \ \ oo_option\ trace\ r\ -command\ \{\n\ \ \ \ \ \ \ \ \ \ \ puts\ \"read\ -command\ value\"\n\ \ \ \ \ \ \ \ \ \ \ return\ \$oo_option(-command)\n\ \ \ \ \ \ \ \}\n\n\ \ \ \ \ \ \ constructor\ \{\ args\ \}\ \{\n\ \ \ \ \ \ \ \ \ oo_option\ initialize\ \$args\n\ \ \ \ \ \ \ \}\n\ \ \ \ \ \}\n======\n\nClearly,\ a\ number\ of\ implementation\ details\ would\ need\ to\ be\ worked\ out.\ The\ general\ idea\ is\ the\ important\ thing\ here.\n\n\ \ \ 5.2\ Object\ aggregation\ support\n\nSection\ L\ outlined\ the\ need\ for\ object\ aggregation\ support.\ The\ question\ remains,\ how\ do\ we\ implement\ it?\ Why\ don't\ we\ use\ the\ \"component\"\ interface\ defined\ by\ itk.\ The\ command\ and\ variable\ named\ would\ need\ to\ be\ changed.\ Perhaps\ oo_component\ would\ work.\n\nHere\ is\ the\ example\ from\ section\ L,\ re-implemented\ using\ an\ oo_component\ style\ interface.\n\n======\n\ \ \ \ \ class\ Member1\ \{\}\n\ \ \ \ \ class\ Member2\ \{\}\n\n\ \ \ \ \ class\ Aggregate\ \{\n\n\ \ \ \ \ \ \ constructor\ \{\ \}\ \{\n\ \ \ \ \ \ \ \ \ \ \ oo_component\ add\ mem1\ \{\n\ \ \ \ \ \ \ \ \ \ \ \ \ Member1\ \$\{this\}_mem1\n\ \ \ \ \ \ \ \ \ \ \ \}\n\ \ \ \ \ \ \ \ \ \ \ oo_component\ add\ mem2\ \{\n\ \ \ \ \ \ \ \ \ \ \ \ \ Member2\ \$\{this\}_mem2\n\ \ \ \ \ \ \ \ \ \ \ \}\n\ \ \ \ \ \ \ \}\n\ \ \ \ \ \}\n======\n\nNote\ that\ component\ objects\ would\ be\ destroyed\ automatically\ when\ the\ containing\ object\ was\ destroyed.\n\n5.3\ Add\ access\ control\ to\ Tcl\n\nIncompatibility\ section\ D\ outlined\ many\ of\ the\ problems\ mapping\ Itcl's\ concept\ of\ access\ control\ to\ Tcl.\ The\ current\ \"half\ and\ half\"\ state\ of\ access\ control\ is\ a\ very\ bad\ thing,\ one\ possible\ solution\ would\ be\ to\ tightly\ integrate\ Itcl's\ access\ control\ rules\ into\ Tcl\ itself.\n\nThis\ would\ be\ a\ major\ overhaul,\ but\ it\ seems\ like\ it\ should\ be\ possible\ to\ do\ this\ in\ a\ backwards\ compatible\ way.\ The\ problem\ with\ this\ approach\ is\ that\ it\ makes\ Tcl\ much\ more\ complex.\ It\ would\ be\ hard\ to\ argue\ that\ \"Itcl\ integration\"\ is\ not\ a\ major\ undertaking\ if\ fundamental\ concepts\ like\ variable\ access\ and\ procedure\ invocation\ need\ to\ be\ re-implemented\ to\ support\ Itcl.\n\n5.4\ Remove\ access\ control\ entirely.\n\nThe\ other\ solution\ to\ the\ problems\ defined\ in\ section\ D\ is\ to\ simply\ yank\ all\ access\ protection\ from\ the\ OO\ system.\ This\ is\ not\ nearly\ as\ drastic\ as\ it\ first\ sounds.\n\nFear\ that\ \"out\ of\ control\ programmers\"\ mucking\ about\ in\ internal\ variables\ will\ cause\ software\ faults\ are\ not\ founded\ in\ reality.\ One\ can\ already\ access\ any\ Itcl\ variable\ with\ the\ help\ of\ the\ itcl::scope\ command.\n\nRemoval\ of\ access\ control\ for\ method\ invocations\ would\ mean\ that\ the\ itcl::code\ method\ would\ no\ longer\ be\ needed.\ You\ don't\ need\ to\ use\ the\ itcl::code\ method\ to\ subvert\ access\ control\ if\ it\ does\ not\ exist.\n\nNote\ that\ I\ am\ only\ talking\ about\ removing\ access\ control\ restrictions\ for\ methods\ invocations.\ I\ think\ the\ public,\ protected,\ and\ private\ modifiers\ should\ be\ retained.\ They\ provide\ good\ documentation\ as\ to\ the\ programmers\ intent.\ Variables\ would\ continue\ to\ make\ use\ of\ these\ modifiers\ to\ control\ which\ variables\ are\ automatically\ made\ accessible\ to\ an\ instance\ method.\n\nIf\ unintended\ method\ invocation\ was\ a\ problem,\ a\ simple\ naming\ convention\ be\ used.\ Tcl\ programmers\ have\ been\ using\ naming\ conventions\ to\ avoid\ command\ clashes\ for\ a\ very\ long\ time.\n\nOne\ serious\ problem\ would\ be\ the\ possibility\ of\ breaking\ existing\ code\ because\ of\ newly\ ambiguous\ method\ invocations.\n\n======\n\ \ \ \ \ itcl::class\ C1\ \{\ public\ method\ foo\ \{\}\ \{\}\ \}\n\ \ \ \ \ itcl::class\ C2\ \{\ private\ method\ foo\ \{\}\ \{\}\ \}\n\ \ \ \ \ itcl::class\ C3\ \{\ inherit\ C1\ C2\ \}\n\n\ \ \ \ \ C3\ c3\n\ \ \ \ \ c3\ foo\n======\n\nIn\ this\ case,\ the\ call\ to\ foo\ would\ be\ ambiguous\ if\ there\ were\ no\ access\ controls.\ One\ could\ argue\ that\ the\ public/protected/private\ keywords\ could\ be\ used\ to\ disambiguate\ this\ method\ invocation,\ but\ I\ am\ not\ sure\ how\ convincing\ that\ would\ be.\n\nRemoving\ access\ control\ for\ method\ invocation\ would\ be\ a\ big\ step,\ but\ it\ would\ significantly\ simplify\ the\ implementation\ of\ OO\ in\ Tcl.\n\n'''The\ net\ effect.'''\n\nAssuming\ each\ layer\ of\ change\ was\ implemented,\ the\nnewly\ integrated\ Tcl+OO\ system\ would\ add\ the\nfollowing\ global\ commands\ to\ Tcl.\n\n\ class\n\ destroy\n\ local\n\ scope\n\nThe\ following\ commands\ would\ defined\ only\nwithin\ a\ class\ body.\n\n\ constructor\n\ destructor\n\ inherit\n\ instance\n\ oo_option\n\ oo_component\n\ proc\n\ private\n\ protected\n\ public\n\nThat's\ it,\ let\ the\ flaming\ commence!\n----\n\[Chang\ Li\]:\ Agree\ 99%.\n----\n\[EMJ\]:\ NO\ -\ I'm\ not\ going\ to\ argue\ with\ any\ of\ the\ detail,\ it's\ the\ principle\ I\ don't\ like.\ \ The\ principle\ is\ called\ '''Feature\ Bloat''',\ and\ that\ is\ not\ in\ the\ spirit\ of\ TCL.\ \ How\ many\ people\ are\ already\ using\ old\ versions\ of\ TCL,\ not\ for\ compatibility\ or\ out\ of\ perversity,\ but\ because\ they\ are\ small\ enough?\n\nIf\ you\ want\ a\ feature\ in\ TCL,\ there\ is,\ or\ will\ be,\ and\ extension\ for\ it.\ \ Extensions\ are\ good,\ just\ pick\ the\ ones\ you\ need.\ \ If\ the\ users\ might\ not\ have\ them,\ build\ a\ \[starkit\]\ for\ them.\n\nIf\ something\ is\ going\ in\ the\ core,\ it\ should\ be:\n\n\ \ \ *\ Of\ benefit\ to\ almost\ everybody\n\n\ \ \ *\ Small\ enough\ (I\ know\ that's\ subjective!)\n----\n\[LV\]\ that's\ why\ the\ \[TIP\]\ that\ was\ approved\ instead\ proposes\ including\n\[itcl\]\ as\ just\ another\ \[extension\].\ \ The\ problem\ is\ that\ to\ do\ either\ will\ require\neffort\ on\ the\ part\ of\ someone\ to\ make\ the\ code\ build\ appropriately.\nThere\ was\ a\ posting\ on\ \[comp.lang.tcl\]\ by\ Donal\ in\ the\ past\ few\ months\nabout\ what\ the\ effort\ would\ be\ to\ finish\ up\ the\ itcl\ TIP.\ \ \n\nEven\ with\ all\ the\ noise\ about\ how\ ''desperate''\ programmers\ need\ OO,\ there\ still\ doesn't\nappear\ to\ be\ even\ one\ of\ these\ desperate\ people\ willing\ to\ work\ through\ the\ issues\nand\ get\ this\ done.\n\n----\n\[SRIV\]\ I've\ been\ using\ \[snit\]\ to\ create\ tcl\ types\ and\ tk\ widgets,\ not\ because\ I\ want\ an\ OO\ programming\ system,\ but\ because\ tcl/tk\ makes\ it\ too\ damn\ hard\ to\ create\ your\ own\ widgets!\ Maybe\ it\ was\ snit's\ easy\ to\ understand\ docs\ that\ enabled\ me.\ Regardless,\ until\ using\ snit,\ I\ never\ used\ any\ OO\ featured\ language.\ But,\ now\ I\ see\ a\ real\ need\ for\nit.\ I\ never\ tried\ Itcl,\ but\ if\ it\ can\ painlessly\ do\ all\ of\ what\ snit\ can\ do,\ and\ enable\ me\ to\ easily\ extend\ tcl/tk\nwith\ new\ or\ compound\ widgets,\ I\ think\ it\ would\ be\ a\ worth\ while\ addition.\ Until\ then,\ \"package\ require\ snit\"\ .\n\n\[DKF\]:\ At\ least\ some\ people\ claim\ that\ \[Snit\]\ makes\ it\ easier\ to\ create\ new\ widgets\ than\ \[Itcl\].\ \n----\n\[RS\]\ How\ is\ it\ hard\ to\ create\ \"your\ own\ widgets\"?\ I\ assume\ you\ mean\ \"megawidgets\"\ composed\ of\ stock\ widgets\ (\"in\ contrast\ to\ Megahertz\ and\ Megabytes,\ a\ megawidget\ isn't\ worth\ a\ million\ widgets\"...)\ Whenever\ I\ need\ some\ custom\ composition\ of\ widgets,\ I\ just\ code\n\n======\n\ proc\ myMega\ \{w\ args\}\ \{\n\ \ \ \ frame\ \$w\n\ \ \ \ thisComponent\ \$w.1\ ...\n\ \ \ \ thatComponent\ \$w.2\ ...\n\ \ \ \ ...\n\ \ \ \ eval\ pack\ \[winfo\ children\ \$w\]\ \;#\ or\ grid,\ or\ whatever\n\ \ \ \ set\ w\ \;#\ so\ the\ caller\ can\ reuse\ it\n\ \}\n======\n\nI\ think\ this\ \[simple\]\ approach\ beats\ worrying\ over\ complex\ frameworks,\ their\ documentation,\ their\ deployment,\ etc.\ But\ of\ course\ I\ also\ use\ \[BWidget\]\ at\ times\ :)\n----\n\[SRIV\]\ yes,\ for\ simple\ cases\ this\ is\ fine.\ In\ my\ case,\ Im\ writing\ a\ tk\ GUI\ builder,\ that\ needs\ to\nquery\ widgets\ for\ their\ options,\ handle\ methods,\ instances\ etc.\ In\ other\ words,\ I\ needed\ the\ megawidget\ to\ behave\ like\ a\ real\ widget\ in\ every\ way.\ Snit\ enabled\ that\ while\ simplifying\ every\ aspect\ \ of\ working\ with\ the\ megawidgets.\ In\ short\ order,\ I\ was\ cranking\ out\ widgets\ one\ after\ another,\ all\ with\ excellent\ results.\ For\ a\ novice\ widget\ builder\ like\ myself,\ snit\ made\ megawidget\ creation\ posible\ \ \ \ \nwith\ simplicity,\ clarity\ and\ speed.\ A\ facility\ that\ has\ long\ been\ lacking\ in\ the\ core.\ \n----\n\[LV\]\ I\ think\ that\ Sriv\ is\ talking\ about\ features\ that\ make\ a\ \[megawidget\]\ a\ megawidget\nrather\ than\ a\ proc\ that\ creates\ a\ complex\ widget.\n\nThe\ ability\ of\ the\ resulting\ creation\ to\ respond\ to\ \[introspection\],\ \nto\ be\ able\ to\ be\ trivially\ configured,\ to\ interact\ with\ the\ option\ndatabase,\ all\ result\ in\ a\ cleaner,\ easier\ to\ reuse\ widget.\n----\nSee\ also\ \[itcl\]\ and\ \[TIP\ #257:\ Object\ Orientation\ for\ Tcl\].\n\n<<categories>>\ Suggestions\ |\ TIP\ |\ Itcl regexp2} CALL {my render {Integrating Itcl into the Tcl core} The\ issue\ in\ the\ page\ title\ is\ an\ extended\ subplot\ in\ the\ history\ of\ Tcl\ development.\ Among\ the\ milestones\ are\ the\ \[TIP\]s:\n\ \ \ #6:\ \ \ ''Include\ \[Incr\ Tcl\]\ in\ the\ Core\ Tcl\ distribution''\ \[http://tip.tcl.tk/6\]\ (rejected)\n\ \ \ #50:\ \ \ ''Bundle\ \[incr\ Tcl\]\ with\ the\ Core\ Tcl\ distribution''\ \[http://tip.tcl.tk/50\]\ (accepted,\ but\ never\ implemented)\n\ \ \ #257:\ \ \ ''Object\ Orientation\ for\ Tcl''\ \[http://tip.tcl.tk/257\]\ (still\ draft)\nIn\ early\ 2007,\ the\ state\ of\ the\ matter\ seems\ to\ be\ that\ acceptance\ of\ TIP\ #257\ will\ make\ the\ matter\ moot\ (it\ won't\ be\ Itcl,\ but\ chances\ are\ that\ noone\ will\ mind\ the\ difference).\ What\ follows\ below\ is\ therefore\ more\ of\ historical\ interest,\ but\ it\ still\ seems\ to\ be\ a\ very\ thorough\ analysis.\n\n----\n\nA\ position\ paper\ by\ Mo\ DeJong.\n''If\ you\ have\ been\ underground\ for\ some\ time\ (perhaps\ waiting\ for\ the\ US\ elections\ to\ end),\ you\ might\ not\ have\ heard\ about\ the\ recent\ talk\ of\ adding\ \[Itcl\]\ to\ the\ \[Tcl\]\ core.''\n\n''I\ took\ it\ upon\ myself\ to\ compile\ a\ list\ of\ some\ of\ the\ issues\ that\ were\ brought\ up\ by\ this\ whole\ \"Integrating\ Itcl\"\ discussion.\ Note\ that\ this\ paper\ has\ not\ been\ proof\ read,\ so\ please\ try\ to\ ignore\ any\ stupid\ spelling\ errors\ and\ the\ like\ :)''\n\ncheers\ -\nMo\ DeJong\ -\nRed\ Hat\ Inc\n----\n\nWhat\ exactly\ am\ I\ talking\ about?\n\n'''Question:'''\nWhat\ is\ the\ best\ way\ to\ integrate\ Object\ Oriented\ functionality\ into\ the\ Tcl\ core?\n\n'''Answer:'''\nIntegrating\ the\ OO\ features\ provided\ by\ Itcl\ into\ the\ Tcl\ core.\ Itcl\ will\ provide\ the\ OO\ support\ that\ programmers\ desperately\ need.\ The\ trick\ here\ will\ be\ doing\ this\ in\ a\ way\ that\ maintains\ the\ \"Tao\ of\ Tcl\".\n\n\ \ \ *\ Not\ talking\ about\ adding\ the\ Itcl\ package\ to\ the\ Tcl\ core.\n\n\ \ \ *\ Not\ talking\ about\ adding\ the\ Itcl\ namespace\ to\ the\ Tcl\ core.\n\nFor\ example,\ there\ would\ be\ no\ itcl::class\ command.\ The\ class\ command\ would\ become\ a\ new\ global\ command.\n\n\ \ \ *\ Itcl\ would\ cease\ to\ exist\ after\ being\ integrated\ into\ the\ core.\n\nThe\ OO\ functionality\ provided\ by\ Itcl\ would\ become\ a\ standard\ part\ of\ the\ Tcl\ language,\ Itcl\ as\ a\ separate\ entity\ would\ cease\ to\ exist\ except\ for\ use\ in\ backwards\ compatibility.\n\n\ \ \ *\ Talking\ about\ doing\ this\ for\ Tcl\ 9.0.\n\nOO\ support\ in\ Tcl\ is\ a\ major\ new\ feature,\ it\ cries\ out\ for\ a\ new\ major\ release\ number.\ Existing\ Itcl\ users\ are\ going\ to\ have\ to\ update\ scripts\ to\ make\ best\ use\ of\ this\ new\ OO\ system.\ Existing\ Tcl\ users\ will\ run\ into\ problems\ is\ they\ define\ commands\ like\ body,\ class,\ or\ the\ like.\ Moving\ to\ a\ new\ major\ release\ will\ give\ users\ an\ obvious\ indication\ that\ they\ may\ need\ to\ re-examine\ script\ during\ an\ upgrade.\n\nWhat\ exactly\ does\ \"Integrate\ Itcl\"\ mean?\nWell,\ it\ depends\ on\ who\ you\ ask.\n\n\ \ \ *\ Some\ will\ tell\ you\ that\ the\ only\ option\ is\ to\ move\ the\ existing\ Itcl\ source\ code\ into\ the\ Tcl\ CVS\ and\ live\ with\ any\ consequences\ or\ incompatibilities.\n\n\ \ \ *\ Some\ will\ tell\ you\ that\ the\ only\ solution\ is\ to\ keep\ Itcl\ as\ a\ separate\ package.\ The\ thinking\ here\ seems\ to\ be\ that\ adding\ OO\ features\ directly\ to\ the\ Tcl\ language\ will\ destroy\ the\ \"procedural\ purity\"\ of\ Tcl.\n\n-\ I\ think\ that\ most\ will\ conclude\ that\ the\ real\ solution\ lies\ somewhere\ between\ these\ extremes.\n\n-\ The\ whole\ notion\ of\ \"compatibility\"\ is\ a\ double\ edged\ sword.\ While\ it\ does\ help\ to\ keep\ old\ code\ working,\ it\ also\ can\ lead\ to\ lack\ of\ improvement\ for\ fear\ of\ effecting\ existing\ code.\n\nWhen\ it\ comes\ to\ integrating\ Itcl\ into\ Tcl,\ compatibility\ with\ existing\ or\ older\ versions\ of\ Itcl\ is\ not\ the\ overwhelming\ concern.\ The\ solution\ that\ has\ been\ discussed\ is\ to\ provide\ a\ backward\ compatibility\ layer\ that\ would\ map\ to\ Itcl\ 3.0\ only.\ This\ would\ provide\ an\ upgrade\ path\ to\ those\ folks\ currently\ running\ with\ Itcl\ 3.0.\n\n'''Change\ is\ bad:'''\n\n-\ Some\ believe\ quite\ strongly\ that\ to\ change\ anything\ about\ Itcl\ is\ an\ attack\ on\ every\ Itcl\ user.\ One\ person\ described\ any\ modification\ to\ Itcl's\ syntax\ or\ semantics\ as\ \"spitting\ in\ the\ eye\ of\ every\ Itcl\ user\".\n\n-\ Others\ contend\ that\ Itcl\ is\ so\ widely\ used\ that\ it\ simply\ must\ be\ \"right\".\ It\ is\ described\ as\ a\ \"proven\ technology\"\ so\ no\ changes\ could\ possibly\ improve\ it.\n\n-\ Still\ others\ content\ that\ \"now\ is\ not\ the\ time\ to\ make\ changes\".\ The\ reasons\ given\ are\ an\ extreme\ sense\ of\ urgency,\ a\ belief\ that\ any\ change\ will\ be\ impossible\ to\ implement,\ or\ that\ anyone\ other\ than\ the\ original\ author\ is\ simply\ unqualified\ to\ even\ suggest\ changes.\n\nI\ have\ asked\ the\ question\ before,\ but\ have\ yet\ to\ hear\ an\ answer.\ If\ not\ now,\ when\ would\ be\ a\ better\ time\ to\ change\ Itcl?\ After\ a\ larger\ base\ of\ Tcl\ users\ have\ begun\ to\ build\ software\ on\ the\ combined\ Tcl+OO\ interface?\ After\ new\ Tcl\ 9.0\ books\ are\ published?\ When\ exactly?\n\n-\ If\ you\ are\ unwilling\ to\ consider\ any\ changes\ to\ Itcl,\ you\ should\ stop\ reading\ now.\n\n'''Change\ is\ good.'''\n\n-\ Improved\ OO\ integration\ can\ lead\ to\ an\ easier\ to\ use\ system.\ Far\ too\ many\ people\ avoid\ Tcl\ because\ they\ hear\ oversimplifications\ like\ \"there\ is\ no\ OO\ in\ Tcl\".\ We\ need\ to\ extend\ the\ Tcl\ user\ base,\ not\ worry\ about\ the\ significantly\ smaller\ group\ of\ existing\ Itcl\ users.\n\n-\ Avoiding\ \"legacy\ issues\"\ is\ a\ serious\ concern.\ What\ seems\ simple\ to\ one\ person\ may\ not\ be\ simple\ to\ someone\ else.\ In\ five\ years,\ nobody\ is\ going\ to\ care\ if\ Itcl\ defined\ the\ variable\ command\ before\ the\ Tcl\ core\ did.\ They\ are\ going\ to\ care\ if\ confusing\ incompatibilities\ exist,\ and\ can\ not\ be\ removed\ because\ of\ backward\ compatibility\ concerns.\n\n-\ Itcl\ contains\ a\ number\ of\ features\ and\ concepts\ that\ are\ fundamentally\ at\ odds\ with\ Tcl.\ If\ we\ avoid\ addressing\ these\ issues\ now\ out\ of\ a\ sense\ of\ expediency,\ we\ could\ be\ making\ it\ harder\ to\ maintain\ and\ improve\ Tcl\ in\ the\ future.\n\n-\ Itcl\ is\ no\ different\ than\ any\ other\ extension.\ It\ is\ not\ \"special\".\ If\ there\ are\ incompatibilities,\ then\ they\ need\ to\ be\ worked\ out\ before\ the\ code\ is\ integrated,\ not\ after.\ We\ can\ not\ subscribe\ to\ the\ theory\ that\ some\ parts\ of\ Tcl\ are\ \"off\ limits\".\n\n-\ Provide\ compatibility\ layer\ for\ older\ code.\ This\ is\ the\ same\ approach\ used\ by\ Itcl\ in\ previous\ releases.\ This\ time,\ it\ would\ be\ implemented\ with\ a\ Tcl\ only\ package\ instead\ of\ keeping\ a\ bunch\ of\ old\ C\ code\ around.\n\n-\ Any\ change\ is\ going\ to\ require\ a\ bit\ of\ rewriting\ and\ updating.\ We\ should\ focus\ on\ how\ we\ can\ improve\ the\ users\ transition\ with\ tools\ like\ the\ Tcl-Pro\ Checker\ and\ Source-Navigator.\n\n'''Itcl\ misconceptions.'''\n\n-\ A\ common\ theme\ seems\ to\ be:\n\n\"Itcl\ has\ been\ stable\ for\ 8\ years,\ you\ can't\ change\ it\ now!\"\n\nIn\ reality,\ there\ have\ been\ major\ overhauls\ of\ the\ syntax\ and\ semantics\ of\ Itcl\ during\ the\ 1.X\ ->\ 2.X\ ->\ 3.X\ transitions.\n\nSome\ have\ contended\ that\ these\ have\ been\ \"minor\ improvements\"\ and\ that\ they\ don't\ matter\ because\ backward\ compatibility\ was\ retained\ along\ the\ way.\ Ironically,\ this\ is\ not\ much\ different\ than\ what\ I\ am\ suggesting.\n\n-\ Itcl\ is\ just\ like\ C++\n\nItcl\ is\ not\ so\ similar\ to\ C++\ that\ it\ is\ immediately\ intuitive.\ There\ are\ plenty\ of\ concepts\ that\ just\ don't\ translate\ between\ the\ two.\ Many\ of\ them\ are\ rooted\ in\ the\ interpreted\ native\ of\ Tcl\ itself.\ \ Some\ diffs\ between\ C++\ and\ Itcl:\n\n-\ the\ access\ keywords\ are\ the\ same\ as\ c++\ but\ the\ defaults\ access\ is\ not.\n\n-\ That\ static\ modifier\ is\ not\ really\ the\ same\ concept\ as\ \"common\".\ The\ static\ modifier\ in\ C++\ is\ applied\ to\ both\ methods\ and\ data.\ Itcl\ generally\ avoids\ the\ concept\ of\ a\ \"modifier\".\ Itcl\ uses\ a\ different\ command\ for\ each\ type\ of\ declaration\ (proc,\ method,\ common,\ variable).\ There\ is\ of\ course\ an\ exception,\ Itcl\ uses\ modifiers\ for\ access\ control\ (public,\ private,\ protected).\n\n-\ Itcl\ is\ bug\ free!\n\nMy\ own\ experience\ seems\ to\ contradict\ the\ assertion\ that\ Itcl\ is\ as\ stable\ as\ the\ Tcl\ core.\n\nI\ have\ used\ Itcl\ sparingly\ in\ the\ past,\ mostly\ because\ it\ was\ not\ part\ of\ the\ \"core\"\ so\ you\ really\ could\ not\ depend\ in\ it\ being\ installed.\n\nI\ now\ hack\ on\ Itcl\ code\ full\ time.\ I\ have\ seen\ many\ of\ the\ legacy\ issues\ from\ the\ perspective\ of\ a\ user\ with\ a\ large\ Itcl\ code-base.\ I\ think\ it\ is\ safe\ to\ say\ that\ Itcl\ is\ not\ as\ stable\ as\ the\ Tcl\ core.\n\nFor\ example,\ a\ new\ C++\ programmer\ might\ try:\n\n======\n\ \ itcl::class\ Toaster\ \{\n\ \ \ \ Toaster\ \{\ name\ \}\ \{\n\ \ \ \ \ \ \ \ puts\ \"Just\ created\ a\ toaster\ named\ \$name\"\n\ \ \ \ \}\n\n\ \ \ \ method\ toastme\ \{\ \}\ \{\n\ \ \ \ \ \ \ \ after\ 5000\ \"set\ toast_done\ 1\"\n\ \ \ \ \ \ \ \ vwait\ toast_done\n\ \ \ \ \}\n\ \ \}\n\n\ \ Segmentation\ fault\n======\n\nClearly,\ this\ is\ not\ the\ most\ effective\ feedback\ Itcl\ could\ provide.\n\nThe\ point\ here\ is\ not\ to\ pick\ on\ Itcl.\ It\ is\ clear\ that\ much\ of\ the\ code\ in\ Itcl\ is\ well\ tested.\ However,\ there\ can\ be\ no\ doubt\ that\ there\ are\ far\ fewer\ Itcl\ users\ than\ there\ are\ Tcl\ users.\ There\ can\ also\ be\ no\ doubt\ that\ Itcl\ has\ historically\ had\ less\ \"support\"\ than\ the\ Tcl\ core.\ With\ fewer\ people\ working\ with\ the\ code\ from\ day\ to\ day,\ nasty\ corner\ cases\ are\ more\ likely\ to\ go\ undetected.\ Only\ by\ incorporating\ the\ OO\ functionality\ provided\ by\ Itcl,\ will\ the\ last\ of\ these\ bugs\ be\ worked\ out.\ I\ would\ hope\ that\ we\ can\ dispense\ with\ the\ notion\ that\ there\ are\ no\ bugs\ in\ Itcl\ and\ move\ forward.\n\n'''What\ concepts/commands\ does\ Itcl\ add?'''\n\n\ -\ classes\n\ -\ instances\ (objects)\n\ -\ instance\ methods\n\ -\ instance\ variables\n\ -\ class\ wide\ methods\ (class\ procs)\n\ -\ access\ control\ for\ methods\n\ -\ automatic\ scoping\ of\ variables\n\ -\ inheritance\ and\ multiple\ inheritance\n\nLet's\ ignore\ the\ older\ backwards\ compatibility\ commands\ included\ in\ Itcl\ 3.0\ for\ the\ sake\ of\ brevity\ here.\ When\ we\ talk\ of\ \"Integrating\ Itcl\"\ what\ we\ are\ really\ talking\ about\ is\ moving\ the\ following\ commands\ from\ the\ itcl\ namespace\ and\ defining\ them\ as\ global\ Tcl\ commands.\n\n\ local\n\ class\n\ body\n\ configbody\n\ ensemble\n\ find\n\ scope\n\ code\n\ delete\n\nIn\ addition,\ there\ are\ the\ commands\ that\ are\ only\ accessible\ while\ a\nclass\ declaration\ is\ being\ evaluated.\ These\ commands\ include:\n\n\ private\n\ protected\n\ public\n\ variable\n\ common\n\ method\n\ proc\n\ constructor\n\ destructor\n\ inherit\n\n'''Object\ creation\ and\ destruction'''\n\nOne\ of\ the\ most\ fundamental\ questions\ that\ needs\ to\ be\ addressed\ is\ how\nobjects\ will\ be\ created\ and\ destroyed.\ Having\ a\ multitude\ of\ ways\ to\ncreate/destroy\ objects\ is\ just\ plain\ confusing.\ We\ must\ define\ the\n\"preferred\ method\"\ of\ object\ allocation\ and\ destruction.\n\nSome\ have\ suggested\ that\ a\ \"new\"\ command\ should\ be\ introduced.\ This\ command\ would\ function\ like\ the\ new\ operator\ in\ languages\nlike\ C++\ or\ Java.\n\n======\n\ %\ set\ obj\ \[\[new\ MyClass\ inst1\]\n======\n\nThis\ sort\ of\ makes\ sense\ when\ you\ consider\ that\ Itcl\ provides\na\ delete\ method.\ In\ addition,\ if\ an\ object\ is\ only\ accessible\nvia\ the\ new\ command,\ one\ would\ have\ less\ worry\ of\ \"pollution\"\nof\ a\ namespace\ with\ lots\ of\ class\ constructor\ commands.\n\nItcl\ currently\ uses\ a\ model\ where\ the\ name\ of\ a\ class\ is\ a\ command\nthat\ invokes\ the\ constructor\ for\ a\ class.\ This\ is\ also\ the\ model\nused\ by\ Tk.\ To\ be\ perfectly\ blunt,\ it\ is\ just\ too\ late\ to\ change\nthe\ way\ Itcl\ objects\ are\ allocated.\ Even\ if\ Itcl\ was\ changed,\ it\ is\nfar\ too\ late\ to\ change\ Tk\ and\ object\ allocation\ in\ Itcl\ and\nTk\ need\ to\ be\ identical.\n\nWhile\ object\ construction\ is\ set\ in\ stone,\ the\ way\ objects\nshould\ be\ destroyed\ is\ not\ so\ clear.\ We\ need\ a\ solution\nthat\ provides\ a\ single\ way\ to\ destroy\ both\ Itcl\ and\ Tk\nobjects.\n\n'''Destruction\ Options:'''\n\n\ \ 1:\ delete\ instance\ command\n\n======\n\ \ %\ \$obj\ delete\n======\n\nThis\ was\ originally\ implemented\ in\ Itcl\ 1.X,\ it\ was\ later\ removed.\ It\ turns\ out\ that\ this\ conflicted\ badly\ with\ Tk\ widgets\ like\ Text,\ the\ already\ define\ a\ delete\ command.\n\n\ \ 2:\ delete\ command\n\n======\n\ \ %\ itcl::delete\ object\ \$obj\n======\n\nThis\ is\ the\ approach\ currently\ employed\ by\ Itcl.\ It\ is\ totally\ incompatible\ with\ the\ destruction\ semantics\ of\ Tk\ widgets.\ This\ alone\ is\ serious\ enough\ to\ warrant\ the\ removal\ of\ this\ command.\n\n\ \ 3:\ rename\ command\n\n======\n\ \ %\ rename\ \$obj\ \{\}\n======\n\nThis\ approach\ is\ also\ used\ in\ the\ current\ version\ of\ Itcl.\ This\ functionality\ can't\ be\ removed\ because\ it\ would\ break\ all\ sorts\ of\ Tk\ scripts.\ It\ should\ be\ replaced\ by\ something\ better\ and\ deprecated.\n\n\ \ 4:\ destroy\ command\n\n======\n\ \ %\ destroy\ \$obj\n======\n\nThis\ approach\ was\ used\ in\ early\ versions\ of\ Itcl.\ The\ problem\ was\ that\ the\ implementation\ was\ not\ transparent.\ The\ destroy\ command\ should\ be\ moved\ into\ Tcl\ in\ a\ way\ that\ makes\ it\ easy\ for\ Tk\ to\ simply\ extend\ the\ functionality\ to\ allow\ transparent\ destruction\ of\ Tk\ widgets.\ I\ will\ avoid\ the\ issue\ of\ raising/quashing\ exceptional\ conditions\ here.\n\nIncompatibility,\ duplicated\ functionality,\ and\ bears.\ Oh\ my!\n\n-\ How\ do\ Itcl\ features\ overlap\ or\ conflict\ with\ Tcl/Tk\ features\ ?\n\nIn\ this\ section\ we\ will\ explore\ how\ some\ Itcl\ features\ conflict,\ overlap,\ or\ fit\ in\ with\ features\ of\ the\ Tcl\ core.\n\n\ A\ -\ Declarations\n\ B\ -\ Class\ re-declaration\n\ C\ -\ Namespaces\n\ D\ -\ Access\ control\n\ E\ -\ Class\ procs\n\ F\ -\ Methods\n\ G\ -\ Option\ management\n\ H\ -\ Callbacks\ and\ access\ control\n\ I\ -\ Working\ around\ scope\ issues\n\ J\ -\ itcl::find\n\ K\ -\ The\ variable\ command\n\ L\ -\ Object\ aggregation\n\n'''A\ -\ Declarations'''\n\nTcl\ does\ not\ support\ the\ concept\ of\ declaring\ the\ way\ something\ should\ be\ used\ before\ it\ is\ used.\ Variables\ are\ set\ to\ a\ scalar,\ array\ type,\ or\ list\ type\ based\ on\ use.\ Procedures\ are\ defined\ at\ runtime,\nand\ are\ not\ declared.\ Tcl\ has\ no\ function\ prototypes.\nItcl\ adds\ the\ concept\ of\ classes\ that\ declare\ what\nfunctions\ they\ support.\ One\ can\ define\ commands\ninside\ a\ class\ definition\ (much\ like\ Java),\nbut\ it\ is\ often\ better\ to\ split\ the\ declaration\nand\ the\ implementation\ of\ class\ methods\ up.\nThis\ helps\ with\ readability\ and\ makes\ tracking\ndown\ syntax\ errors\ easier.\n\nItcl\ requires\ that\ you\ declare\ instance\ commands\n(methods)\ and\ class\ wide\ commands\ (class\ procs)\ndifferently,\ but\ it\ has\ no\ support\ for\ declaring\nthe\ type\ of\ a\ variable\ at\ class\ definition\ time.\n\nFor\ instance:\n\n======\n\ itcl::class\ Foo\ \{\n\ \ \ variable\ foo\n\ \}\n======\n\nBut\ not:\n\n======\n\ itcl::class\ Foo\ \{\n\ \ \ array\ variable\ foo\n\ \}\n======\n\n\n'''B\ -\ Class\ re-declaration'''\n\n\nA\ class\ can\ not\ be\ redefined.\ This\ directly\ncontradicts\ the\ semantics\ of\ variable\nand\ proc\ definitions.\ Some\ have\ suggested\nthat\ .h\ files\ are\ the\ best\ way\ to\ avoid\nany\ problems\ this\ causes.\ I\ frankly\ndon't\ see\ a\ need\ for\ the\ added\ complexity.\nRedefining\ a\ class\ should\ be\ the\ same\ as\ncalling\ \"itcl::delete\ class\ Foo\"\ and\ then\nrunning\ the\ class\ command\ again.\n\nThe\ argument\ has\ been\ made\ that\ this\ actually\nhelps\ programmers\ in\ the\ case\ where\ the\ same\nclass\ name\ is\ accidently\ used\ in\ two\ncompletely\ different\ files\ or\ modules.\nTcl\ has\ never\ provided\ this\ sort\ of\ \"help\".\nIn\ Tcl,\ the\ same\ proc\ or\ variable\ncan\ be\ created,\ deleted,\ or\ redefined\nin\ any\ file\ without\ having\ to\ worry\ that\nit\ had\ been\ defined\ elsewhere.\n\nThe\ most\ common\ way\ one\ would\ run\ into\nthis\ problem\ would\ be\ to\ source\ a\ file\nthat\ contained\ a\ class\ declaration\ntwice.\ The\ second\ time\ you\ run\n\[\[source\ foo.tcl\]\ an\ error\ would\nbe\ raised\ by\ the\ class\ command.\nThere\ is\ of\ course\ a\ trivial\noptimization\ one\ could\ employ\nhere.\ If\ a\ new\ class\ declaration\nis\ exactly\ the\ same\ as\ the\ old\none,\ simply\ do\ nothing.\n\n\n'''C\ -\ Namespaces'''\n\nItcl\ makes\ use\ of\ Tcl\ namespaces,\ but\ it\nalso\ adds\ additional\ features\ on\ top\non\ the\ existing\ namespace\ support\nprovided\ by\ Tcl.\ There\ is\ a\ long\nhistory\ of\ disagreement\ over\ the\nissue\ of\ access\ control\ and\ how\nit\ relates\ to\ namespaces.\n\n\ -\ Access\ control\ was\ not\ provided\ in\ Tcl\ 8.0\n\ -\ Ancestor\ based\ cmd/var\ lookup\ was\ not\ provided\ in\ Tcl\ 8.0\n\nIn\ Itcl\ 3.0,\ the\ ancestor\ based\ cmd/var\ lookup\nfeatures\ support\ was\ dropped.\ Access\ control\non\ the\ other\ hand,\ was\ retained.\n\nThe\ differences\ between\ namespaces\ and\ Itcl\nclasses\ is\ the\ cause\ of\ much\ confusion.\nI\ have\ also\ heard\ the\ opinion\ expressed\ that\nas\ soon\ as\ people\ have\ access\ to\ classes,\ they\nwill\ no\ longer\ need\ to\ worry\ about\ namespaces.\n\nThis\ \"solution\"\ to\ the\ problem\ of\ incompatibilities\nbetween\ Itcl\ and\ Tcl\ is\ not\ much\ help.\ Either\nTcl\ namespaces\ need\ to\ be\ changed\ so\ that\nthey\ provide\ functionality\ that\ Itcl\ requires\nor\ Itcl\ will\ need\ to\ be\ modified\ to\ require\nonly\ the\ functionality\ that\ Tcl\ namespace\nprovide.\ If\ people\ are\ having\ trouble\ seeing\nhow\ namespaces\ and\ classes\ fit\ together,\nperhaps\ it\ is\ because\ they\ do\ not.\ We\nneed\ to\ address\ the\ issue\ and\ not\ gloss\nover\ it\ with\ \"quick\ fixes\".\n\n\n'''D\ -\ Access\ Control'''\n\nTcl\ provides\ no\ support\ for\ access\ control.\ Both\nvariables\ and\ procedures\ can\ be\ freely\ modified\nby\ any\ part\ of\ a\ Tcl\ program.\ There\ tend\ to\ be\na\ couple\ reasons\ to\ put\ access\ controls\ on\ variables\nand\ procedures.\ One\ reason\ is\ to\ stop\ programmers\nfrom\ accidently\ accessing\ a\ method\ or\ data.\ If\ two\ndifferent\ modules\ accidently\ used\ the\ same\ global\nvariable,\ the\ result\ could\ be\ a\ disaster.\ Access\ncontrol\ also\ plays\ a\ documentation\ role.\ If\ a\nvariable\ or\ method\ is\ declared\ \"private\",\ that\nwould\ provide\ a\ very\ good\ hint\ that\ the\ author\ndid\ not\ want\ you\ to\ use\ that\ function\ from\ outside\nthe\ given\ class.\ Not\ being\ able\ to\ call\ a\ private\nmethod\ from\ the\ public\ instance\ handle\ is\ a\ good\nclue\ that\ you\ not\ meant\ to\ use\ it.\ Itcl's\ access\ncontrol\ policy\ does\ make\ it\ harder\ to\ get\naccess\ to\ private\ data,\ but\ it\ does\ not\ actually\nstop\ anyone\ from\ reading\ or\ writing\ variables\ or\ncalling\ private\ methods\ from\ outside\ of\ the\ class\ scope.\n\nAccess\ control\ is\ currently\ in\ a\ \"half\ and\ half\"\ state.\nTcl\ namespaces\ do\ not\ implement\ any\ sort\ of\ access\ncontrol.\ Itcl\ tries\ to\ layer\ its\ own\ notions\ of\naccess\ control\ on\ top\ of\ Tcl\ namespaces,\ which\ncauses\ some\ problems.\n\n\n======\n\ itcl::class\ DontCallMe\ \{\n\ \ \ \ private\ proc\ argh\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \$msg\n\ \ \ \ \}\n\n\ \ \ \ private\ common\ msg\ \"ARRRAGH!\"\n\ \}\n\n\ %\ namespace\ eval\ DontCallMe\ \{argh\}\n\ ARRRAGH!\n\n\ %\ set\ DontCallMe::msg\ \"WOHOOO!!\"\n\n\ %\ namespace\ eval\ DontCallMe\ \{argh\}\n\ WOHOOO!!\n======\n\n\nNote\ how\ in\ the\ above\ example,\ we\ncan\ directly\ set\ a\ private\ class\nvariable\ and\ we\ can\ call\na\ private\ method\ by\ simply\ adding\na\ namespace\ eval.\ In\ fact,\ this\nis\ exactly\ what\ the\ itcl::code\nmethod\ does.\n\nLet's\ face\ it,\ control\ is\ complex!\nMisuse\ of\ access\ control\ can\ easily\nlead\ to\ some\ really\ tricky\ bugs.\n\nIn\ this\ example\ we\ see\ how\nItcl's\ existing\ access\ control\nfeatures\ can\ be\ misused\ in\na\ way\ that\ breaks\ perfectly\ngood\ code.\ One\ can\ redefine\nsubclass\ method\ access\nin\ a\ way\ that\ break\ the\nAPI\ of\ the\ parent\ class\nwith\ respect\ to\ an\ isa\ test.\n\n\n======\n\ itcl::class\ Base\ \{\n\ \ \ \ public\ method\ doit\ \{\}\ \{\n\ \ \ \ \ \ \ \ return\ XJ45.1\n\ \ \ \ \}\n\ \}\n\n\n\ proc\ print_base\ \{\ base\ \}\ \{\n\ \ if\ \{\[\[\$base\ isa\ Base\]\}\ \{\n\ \ \ \ \ \ puts\ \"!!!!!\ \[\[\$base\ doit\]\ !!!!\"\n\ \ \}\ else\ \{\n\ \ \ \ \ \ puts\ \"not\ derived\ from\ Base\"\n\ \ \}\n\ \}\n\n\n\ %\ Base\ b\n\ %\ print_base\ b\n\ !!!!!\ XJ45.1\ !!!!\n======\n\n\nAnd\ now\ for\ a\ subclass:\n\n======\n\ itcl::class\ Derived\ \{\n\ \ \ \ inherit\ Base\n\n\ \ \ \ private\ method\ doit\ \{\}\ \{\n\ \ \ \ \ \ \ \ return\ XJ45.2\n\ \ \ \ \}\n\ \}\n\n\ %\ Derived\ d\n\ %\ print_base\ d\n\ bad\ option\ \"doit\":\ should\ be\ one\ of...\n\ \ d\ cget\ -option\n\ \ d\ configure\ ?-option?\ ?value\ -option\ value...?\n\ \ d\ isa\ className\n======\n\n\nThis\ example\ shows\ how\ one\ can\ break\nthe\ isa\ relationship\ by\ misusing\naccess\ controls.\n\n\n'''E\ -\ Class\ procs'''\n\nThese\ sorts\ of\ procs\ are\ defined\ with\ the\ itcl::body\ command.\nThey\ are\ subtly\ different\ than\ regular\ Tcl\ procs.\ For\ instance,\nin\ a\ class\ proc\ variables\ defined\ as\ common\ are\ accessible\ by\ndefault.\ A\ regular\ Tcl\ proc\ only\ has\ access\ to\ local\ variables\nby\ default.\ Procs\ defined\ with\ the\ body\ command\ also\ make\nuse\ of\ access\ control,\ regular\ Tcl\ procs\ have\ no\ access\nprotection.\n\n\nAt\ first\ glance,\ these\ two\ bits\ of\ code\ might\nseem\ like\ they\ do\ the\ same\ things:\n\n======\n\ namespace\ eval\ Two\ \{\n\ \ \ \ proc\ gak\ \{\ \}\ \{\n\ \ \ \ \ \ return\ GAK2\n\ \ \ \ \}\n\ \}\n\n\ %\ Two::gak\n\ GAK1\n\n\ itcl::class\ One\ \{\n\ \ \ \ proc\ gak\ \{\ \}\ \{\n\ \ \ \ \ \ return\ GAK1\n\ \ \ \ \}\n\ \}\n\n\ %\ One::gak\n\ GAK2\n======\n\nBut,\ when\ you\ introduce\ a\ variable\ninto\ the\ mix,\ the\ difference\ shows.\n\n======\n\ namespace\ eval\ Two\ \{\n\ \ \ \ variable\ result\ GAK1\n\n\ \ \ \ proc\ gak\ \{\ \}\ \{\n\ \ \ \ \ \ return\ \$result\n\ \ \ \ \}\n\ \}\n\n\ %\ Two::gak\n\ can't\ read\ \"result\":\ no\ such\ variable\n\n\ itcl::class\ One\ \{\n\ \ \ \ common\ result\ GAK1\n\n\ \ \ \ proc\ gak\ \{\ \}\ \{\n\ \ \ \ \ \ return\ \$result\n\ \ \ \ \}\n\ \}\n\n\ %\ One::gak\n\ GAK2\n======\n\nOne\ needs\ to\ explicitly\ make\ a\ namespace\nvariable\ visible\ to\ a\ regular\ Tcl\ proc\ndefined\ in\ a\ namespace.\n\n\n======\n\ namespace\ eval\ Two\ \{\n\ \ \ \ variable\ result\ GAK2\n\n\ \ \ \ proc\ gak\ \{\ \}\ \{\n\ \ \ \ \ \ variable\ result\n\ \ \ \ \ \ return\ \$result\n\ \ \ \ \}\n\ \}\n\n\ %\ Two::gak\n\ GAK2\n======\n\n\nThe\ new\ \"class\ proc\"\ type\ also\nmakes\ it\ impossible\ to\ declare\na\ regular\ proc\ in\ a\ class\ndefinition.\ One\ would\ need\ to\nsurround\ a\ proc\ definition\nwith\ a\ \[\[namespace\ eval\]\ to\nget\ a\ similar\ effect.\n\nThe\ whole\ concept\ of\ a\n\"class\ proc\"\ is\ in\ conflict\nwith\ the\ behavior\ and\nmethod\ of\ declaration\ of\nregular\ Tcl\ procs.\n\nThere\ is\ also\ reason\ to\nbe\ concerned\ about\ the\nway\ itcl::body\ duplicates\nfunctionality\ seemingly\ncovered\ by\ the\ proc\ command.\nTcl\ has\ always\ had\ one\nway\ of\ declaring\ a\ proc,\nwith\ the\ proc\ command.\nWe\ need\ to\ think\ long\ and\nhard\ about\ our\ options\nbefore\ changing\ that.\n\n\n\n'''F\ -\ Methods'''\n\nInstance\ methods\ are\ the\ second\ type\nof\ new\ command\ added\ by\ Itcl.\ Methods\nare\ different\ than\ regular\ procs,\nsince\ they\ can\ only\ be\ invoked\ on\na\ valid\ object\ instance.\n\nHere\ is\ a\ quick\ example\ of\ how\nthey\ are\ currently\ defined\ using\nitcl::body.\n\n======\n\ itcl::class\ Example\ \{\n\ \ \ \ private\ proc\ foo\ \{\}\n\ \ \ \ private\ method\ bar\ \{\}\n\ \}\n\n\ itcl::body\ Example::foo\ \{\}\ \{\n\ \ \ \ puts\ \"called\ foo\"\n\ \}\n\n\ itcl::body\ Example::bar\ \{\}\ \{\n\ \ \ \ puts\ \"called\"\n\ \}\n======\n\n\nMethods\ are\ not\ really\ incompatible\nwith\ anything\ in\ Tcl,\ but\ the\ way\nthey\ are\ defined\ is.\n\nTcl\ has\ always\ used\ the\ proc\ command\nfor\ this\ sort\ of\ thing.\ We\ need\ to\nbe\ absolutely\ sure\ that\ adding\ a\ntoplevel\ \"body\"\ command\ to\ Tcl\ is\nreally\ the\ optimal\ solution.\ I\ am\nnot\ convinced\ that\ it\ is.\n\n\n\n'''G\ -\ Option\ management'''\n\nItcl's\ concept\ of\ configurable\ options\ is\ntightly\ coupled\ with\ \"public\ variables\".\nThese\ public\ variables\ can\ be\ declared\nonly\ when\ the\ class\ is\ created.\nThis\ approach\ works\ well\ for\ simple\ cases,\nbut\ it\ fails\ to\ meet\ the\ needs\ of\ more\ncomplex\ applications.\n\nEvidence\ of\ this\ can\ be\ found\ in\ itk,\ the\nmega-widget\ based\ framework\ build\ on\ top\nof\ Itcl.\ Instead\ of\ using\ itcl\ style\npublic\ variables,\ Itk\ stores\ object\nconfiguration\ options\ in\ an\ array\nnamed\ itk_option.\n\nThis\ make\ it\ possible\ to\ add\ an\ option\ninside\ an\ object's\ constructor,\ something\nthat\ you\ simply\ can't\ do\ in\ Itcl.\ The\ fact\nthat\ Itk\ uses\ its\ own\ option\ configuration\nsystem\ can\ lead\ to\ some\ serious\ problems\ when\nmixing\ Itcl\ and\ Itk\ based\ objects.\n\nHere\ is\ a\ quick\ example:\n\n======\n\ itcl::class\ Foo\ \{\n\ \ \ \ inherit\ itk::Widget\n\n\ \ \ \ public\ variable\ myoption\ off\n\ \}\n\n\ %\ Foo\ .f\n\ %\ .f\ cget\ -myoption\n\ unknown\ option\ \"-myoption\"\n======\n\nConfused?\ You\ should\ be.\n\nThis\ error\ is\ a\ side\ effect\ of\ itk's\ implementation.\nItk\ replaces\ Itcl's\ public\ variable\ based\ option\nconfiguration,\ and\ rightly\ so.\ An\ option\ system\nthat\ is\ statically\ defined\ at\ class\ declaration\ntime\ is\ at\ odds\ with\ the\ dynamic\ needs\ of\nmega-widget\ systems.\n\nOptions\ also\ have\ their\ own\ special\ sort\ of\ncallbacks,\ and\ a\ special\ way\ to\ define\nthese\ callbacks.\n\nThe\ itcl::configbody\ command\ supports\ a\ sort\nof\ inlined\ trace\ method\ that\ in\ run\ninside\ the\ scope\ of\ an\ instance\ when\nan\ option\ is\ configured.\ When\ a\ user\ runs\n\n======\n\ %\ \$obj\ configure\ -foo\ bar\n======\n\na\ configbody\ callback\ for\ the\ -foo\ option\nis\ called.\ The\ configbody\ is\ a\ bit\ of\ a\nstrange\ mix\ between\ a\ variable\ trace\nand\ an\ instance\ method.\n\nIt\ can\ be\ handy,\ but\ it\ also\ adds\ an\nadditionally\ layer\ of\ functionality\nthat\ could\ be\ implemented\ without\nthe\ need\ to\ introduce\ a\ new\nglobal\ \"configbody\"\ command.\n\nThe\ configbody\ command\ also\ has\ a\nmajor\ shortcoming.\ The\ configbody\ncommand\ is\ like\ a\ write\ trace,\ but\nthere\ is\ no\ support\ for\ a\ read\ntrace\ on\ an\ option.\ This\ is\ a\nserious\ problem,\ you\ can\ work\ around\nit\ but\ it\ is\ not\ easy\ or\ fun.\n\nIt\ is\ just\ not\ clear\ that\ the\nfunctionality\ provided\ by\ the\nconfigbody\ command\ is\ important\nenough\ to\ require\ the\ addition\nof\ a\ global\ Tcl\ command\ for\ it.\n\n'''H\ -\ Callbacks\ and\ access\ control'''\n\nThe\ itcl::code\ command\ provides\ a\nway\ to\ bypass\ access\ control\nfor\ Itcl\ procs\ and\ methods.\n\nExample:\n\n======\nset\ cmd\ \"\"\n\nitcl::class\ Example\ \{\n\ \ \ \ constructor\ \{\}\ \{\n\ \ \ \ \ \ \ \ global\ cmd\n\ \ \ \ \ \ \ \ set\ cmd\ \[\[itcl::code\ \$this\ foo\]\n\ \ \ \ \}\n\n\ \ \ \ private\ method\ foo\ \{\}\ \{\n\ \ \ \ \ \ \ \ puts\ \"called\ foo\ for\ \$this\"\n\ \ \ \ \}\n\}\n\n%\ Example\ e1\ne1\n\n#\ Run\ the\ callback\ saved\ in\ \$cmd\n%\ eval\ \$cmd\ncalled\ foo\ for\ ::e1\n======\n\nThe\ itcl::code\ command\ works\ by\ncreating\ a\ \"backdoor\"\ into\nthe\ Example\ namespace,\ like\ so:\n\n======\n%\ set\ cmd\nnamespace\ inscope\ ::Example\ \{::e1\ foo\}\n======\n\nOf\ course,\ the\ constructor\ for\nthe\ Example\ class\ could\ have\nbeen\ coded\ without\ the\ itcl::code\nmethod,\ but\ it\ would\ have\ been\nslightly\ uglier:\n\n======\n\ \ \ \ constructor\ \{\}\ \{\n\ \ \ \ \ \ \ \ global\ cmd\n\ \ \ \ \ \ \ \ set\ cmd\ \[\[namespace\ inscope\ \\\n\ \ \ \ \ \ \ \ \ \ \ \ \[\[namespace\ current\]\ \[\[list\ \$this\ foo\]\]\n\ \ \ \ \}\n======\n\n'''I\ -\ Working\ around\ scope\ issues'''\n\nThe\ itcl::scope\ command\ provides\ a\n\"backdoor\"\ for\ variable\ scope.\ There\ is\nno\ access\ control\ for\ variables.\ You\ncan\ always\ set\ a\ variable\ as\ long\ as\nyou\ know\ the\ full\ scope\ of\ the\ variable\nname.\ The\ itcl::scope\ command\ provides\na\ handy\ way\ to\ get\ this\ info.\n\nThe\ ability\ to\ access\ instance\nvariables\ using\ the\ scope\ command\nwas\ added\ for\ Itcl\ 3.0.\ This\nis\ an\ incredibly\ useful\ feature,\nespecially\ for\ Tk\ GUIs.\ Older\nversions\ of\ Itcl\ required\ the\nsame\ global\ array\ indexing\nhacks\ that\ are\ blamed\ for\ the\npoor\ performance\ and\ readability\nof\ tcllib.\n\n\nA\ quick\ example:\n\n======\nset\ var\ \"\"\n\nitcl::class\ Example\ \{\n\ \ \ \ constructor\ \{\}\ \{\n\ \ \ \ \ \ \ \ global\ var\n\ \ \ \ \ \ \ \ set\ var\ \[\[itcl::scope\ _name\]\n\ \ \ \ \}\n\n\ \ \ \ private\ variable\ _name\ \"bob\"\n\}\n======\n\n\nNote\ that\ unlike\ the\ itcl::code\ncommand,\ the\ itcl::scope\ command\ndoes\ not\ require\ that\ you\ pass\ the\nname\ of\ instance\ variable\ \$this.\n\n======\n%\ Example\ e1\ne1\n\n%\ set\ \[\[set\ var\]\nbob\n======\n\nThis\ works\ because\ itcl::scope\ lets\nus\ bypass\ any\ access\ protection\nand\ directly\ access\ the\ instance\ var.\n\n\nHere\ is\ how\ it\ is\ implemented:\n\n======\n%\ set\ var\n@itcl\ ::e1\ ::Example::_name\n======\n\nThe\ above\ list\ may\ not\ look\ like\ other\nTcl\ variable\ names,\ it\ is\ not.\ It\nis\ a\ special\ form\ of\ a\ variable\ name\nknown\ only\ to\ Itcl.\ Itcl\ uses\ a\ C\ API\nto\ register\ a\ custom\ variable\ name\nresolver\ when\ it\ is\ loaded\ into\ Tcl.\n\nThe\ issue\ with\ scoping\ is\ not\ so\ much\nan\ incompatibility\ with\ Tcl\ as\ much\ as\ it\ is\na\ new\ feature\ that\ the\ core\ may\ need\ to\nsupport\ directly.\ One\ possible\ modification\nwould\ be\ to\ use\ a\ separator\ other\ than\ space\nin\ the\ variable\ name.\ There\ will\ be\ code\nthat\ assumes\ variable\ names\ do\ not\ have\nspaces\ in\ them,\ for\ instance\ when\ a\ var\ name\nis\ passed\ to\ an\ eval.\ I\ assume\ that\ a\ toplevel\nscope\ command\ would\ be\ created,\ but\ there\ are\ncertainly\ other\ options\ if\ avoiding\ namespace\npollution\ is\ a\ big\ issue.\n\n'''J\ -\ itcl::find\ command'''\n\nThe\ itcl::find\ command\ was\ originally\ incorporated\ninto\ the\ info\ command.\ It\ should\ be\ put\ back.\nThere\ is\ no\ justification\ for\ adding\ a\ toplevel\nfind\ command\ just\ to\ support\ searching\ for\ objects.\n\nIt\ might\ also\ be\ useful\ to\ look\ into\ adding\ a\nway\ to\ determine\ if\ an\ object\ exists\ without\nhaving\ to\ compare\ to\ a\ named\ object\ result.\nThis\ would\ make\ the\ users\ life\ easier\ and\nwould\ surely\ execute\ more\ quickly\ than\nthe\ current\ solution.\ It\ would\ be\ like\nthe\ winfo\ exists\ command,\ but\ for\ objects.\n\n\n\n'''K\ -\ The\ variable\ command'''\n\nItcl's\ variable\ command\ is\ in\ conflict\nwith\ Tcl's\ variable\ command.\ In\ fact,\nthey\ are\ almost\ exact\ opposites.\n\nHere\ is\ a\ quick\ example.\n\n======\n\ namespace\ eval\ One\ \{\n\ \ \ \ variable\ Number\ 1\n\ \}\n\n\ %\ set\ One::Number\n\ 1\n\n\n\ itcl::class\ Two\ \{\n\ \ \ \ variable\ Number\ 2\n\ \}\n\n\ %\ set\ Two::Number\n\ can't\ read\ \"Two::Number\":\ no\ such\ variable\n======\n\n\nWhy\ ,you\ ask?\n\nItcl\ uses\ the\ variable\ command\ to\ndefine\ an\ instance\ variable.\ Tcl\nuses\ the\ variable\ command\ to\ declare\na\ namespace\ variable,\ similar\ to\na\ common\ variable\ in\ Itcl.\n\nlike\ so:\n\n======\n\ itcl::class\ Two\ \{\n\ \ \ \ common\ Number\ 2\n\ \}\n\n\ %\ set\ Two::Number\n\ 2\n======\n\n\nI\ personally\ find\ the\ common\ command\na\ bit\ confusing.\ It\ does\ not\ make\ it\nparticularly\ obvious\ that\ the\ thing\nbeing\ declared\ is\ a\ variable.\ When\nyou\ combine\ common\ with\ and\ inlined\nvariable\ initialization\ and\ an\ninlined\ configbody\ callback,\ the\nresult\ can\ end\ up\ looking\ a\ lot\nlike\ a\ method\ declaration.\n\n======\n\ itcl::class\ Two\ \{\n\ \ \ \ common\ Number\ \{one\ two\}\ \{\n\ \ \ \ \ \ puts\ \"called\ me\"\n\ \ \ \ \}\n\ \}\n======\n\n'''L\ -\ Object\ aggregation'''\n\nItcl\ has\ no\ built-in\ support\ for\nobject\ aggregation!\ It\ is\ really\ quite\nbaffling.\ Object\ aggregation\ is\ an\nincredibly\ useful\ concept\ and\ it\nis\ well\ supported\ in\ languages\nlike\ C++\ and\ Java.\n\n\nHere\ is\ a\ quick\ example:\n(C++)\n\n======c++\n\ class\ Member1\ \{\}\;\n\ class\ Member2\ \{\}\;\n\n\ class\ Aggregate\ \{\n\ \ Member1\ mem1\;\n\ \ Member2\ mem2\;\n\ \}\;\n\n\ (Java)\n\n\ class\ Member1\ \{\}\n\ class\ Member2\ \{\}\n\n\ class\ Aggregate\ \{\n\ \ Member1\ mem1\ =\ new\ Member1()\;\n\ \ Member2\ mem2\ =\ new\ Member2()\;\n\ \}\n======\n\n\nTo\ do\ this\ same\ thing\ in\ Itcl,\nthe\ programmer\ needs\ to\ allocate\nand\ free\ the\ objects\ by\ hand.\n\n======\n\ itcl::class\ Member1\ \{\}\n\ itcl::class\ Member2\ \{\}\n\n\ itcl::class\ Aggregate\ \{\n\ \ variable\ mem1\n\ \ variable\ mem2\n\n\ \ constructor\ \{\ \}\ \{\n\ \ \ \ set\ mem1\ \[\[Member1\ \$\{this\}_mem1\]\n\ \ \ \ set\ mem2\ \[\[Member2\ \$\{this\}_mem2\]\n\ \ \}\n\n\ \ destructor\ \{\n\ \ \ \ itcl::delete\ object\ \$mem1\ \$mem2\n\ \ \}\n\ \}\n======\n\n\n'''Layers\ of\ Change'''\n\nNow\ for\ the\ fun\ stuff!\ In\ this\ section\ I\npresent\ some\ suggested\ changes\ to\ better\nintegrate\ Itcl\ into\ the\ Tcl\ core.\ Each\nlayer\ suggests\ more\ comprehensive\ changes\nthan\ the\ previous\ one,\ and\ some\ changes\nbuild\ upon\ the\ previous\ layer.\n\nThese\ suggestions\ assume\ that\ backwards\ncompatibility\ would\ be\ dealt\ with\ using\na\ loadable\ package\ that\ would\ wrap\ around\nthe\ new\ implementation.\n\n'''Layer\ 0:'''\nNo\ changes!\n\nThis\ approach\ would\ simply\ move\ all\ the\ Itcl\ commands\ into\ the\ global\ namespace.\ This\ is\ an\ all\ or\ nothing\ approach.\ It\ is\ not\ going\ to\ be\ possible\ to\ move\ some\ Itcl\ commands\ into\ the\ global\ namespace\ and\ leave\ some\ in\ the\ itcl\ namespace.\ That\ would\ only\ serve\ to\ break\ the\ scripts\ of\ folks\ that\ run\ \[\[namespace\ import\ itcl::*\].\ Still,\ not\ everyone\ is\ going\ to\ be\ happy.\ There\ will\ be\ folks\ that\ use\ the\ itcl::\ prefix\ for\ method\ invocations,\ those\ scripts\ will\ be\ broken\ by\ this\ approach.\n\nThe\ \"no\ changes\"\ approach\ would\ most\ benefit\ those\ who\ already\ have\ large\ applications\ written\ in\ Itcl.\ The\ benefit\ being\ they\ would\ not\ need\ to\ rewrite\ an\ application\ that\ was\ written\ to\ the\ Itcl\ 3.0\ API.\n\nIf\ the\ application\ used\ any\ older\ 1.X\ or\ 2.X\ APIs\ that\ are\ still\ supported\ in\ Itcl\ 3.0,\ it\ would\ not\ work\ with\ the\ new\ integrate\ OO\ system.\ Solving\ that\ legacy\ code\ problem\ would\ mean\ introducing\ even\ more\ toplevel\ command\ like\ itcl_class\ and\ so\ on.\ It\ is\ a\ slippery\ slope,\ we\ need\ to\ cleanly\ integrate\ Itcl\ 3.X,\ and\ use\ add\ on\ packages\ for\ backwards\ compatibility.\ It\ seems\ obvious\ that\ the\ best\ people\ to\ implement\ such\ a\ wrapper\ would\ be\ those\ folks\ with\ a\ vested\ interest\ in\ getting\ legacy\ code\ running\ on\ the\ OO\ enabled\ Tcl\ core.\n\nSome\ folks\ contend\ that\ Layer\ 0\ is\ the\ only\ valid\ option.\ They\ claim\ that\ any\ syntactic\ or\ semantic\ change\ will\ alienate\ current\ Itcl\ users.\ While\ this\ is\ a\ concern,\ it\ is\ not\ predominant.\n\n\n'''Layer\ 1:'''\nChanges\ that\ are\ not\ likely\ to\ cause\ incompatibilities\ and\ will\ fix\ real\ problems\ or\ simply\ remove\ obsolete\ code.\n\n1.1\ Constructors\ must\ return\ fully\ qualified\ names:\n\n\ \ \ *\ This\ would\ fix\ a\ number\ of\ problems\ related\ to\ passing\ objects\ from\ namespace\ to\ namespace.\n\ \ \ *\ This\ would\ remove\ the\ need\ to\ itk_component(hull)\ in\ itk\ code.\n\ \ \ *\ A\ small\ change\ to\ Tk\ would\ be\ required\ to\ implement\ this\ properly.\ Fetching\ a\ window\ name\ would\ implicitly\ do\ a\ \[\[namespace\ tail\ \$w\]\].\n\n1.2\ Remove\ class\ autoloading\n\n\ \ \ *\ This\ is\ obsolete\ code,\ it\ was\ only\ left\ in\ Itcl\ 3\ for\ backwards\ compatibility\ reasons.\n\n1.3\ Disallow\ dynamic\ method\ invocation\ in\ constructor\n\nThe\ problem\ is\ described\ here:\n\n\ \ \ \ \ http://dev.scriptics.com/lists/itcl/2000/11/msg00031.html\ (Link\ is\ dead.\ No\ replacement\ found\ yet)\n\nThe\ solution\ is\ to\ simply\ not\ allow\ it.\n\n1.4\ Disallow\ dangerous\ method\ protection\ changes\n\nThe\ problem\ is\ described\ in\ incompatibilities\ section\ D.\ Changes\ that\ break\ an\ object's\ isa\ relationship\ should\ not\ be\ allowed.\n\n1.5\ Allow\ redefinition\ of\ classes\n\nThe\ class\ command\ should\ not\ raise\ an\ error\ when\ duplicate\ class\ is\ encountered.\ If\ the\ class\ declaration\ has\ changed,\ the\ system\ should\ call\ \[\[itcl::delete\ class\ \$class\]\ and\ then\ redefine\ it.\ In\ the\ trivial\ case\ where\ the\ exact\ same\ declaration\ body\ is\ twice,\ the\ second\ declaration\ can\ simply\ be\ ignored.\ We\ should\ not\ force\ Tcl\ programmers\ into\ a\ C/C++\ style\ model\ where\ .h\ file\ are\ the\ norm.\n\n\n'''Layer\ 2:'''\nIncorporation\ of\ Itcl\ functionality\ into\ existing\ Tcl\ commands.\n\n2.1\ proc\ command\ can\ replace\ the\ body\ command\n\nThis\ will\ address\ incompatibilities\ discussed\ in\ sections\ E\ and\ F.\ The\ existing\ class\ declaration\ syntax\ would\ still\ be\ used,\ but\ the\ proc\ command\ would\ be\ substituted\ for\ the\ itcl::body\ command.\n\n======\n\ \ \ \ \ class\ Example\ \{\n\ \ \ \ \ \ \ proc\ foo\ \{\}\n\ \ \ \ \ \ \ method\ bar\ \{\}\n\ \ \ \ \ \}\n\n\ \ \ \ \ proc\ Example::foo\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ foo\"\n\ \ \ \ \ \}\n\n\ \ \ \ \ proc\ Example::bar\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ bar\"\n\ \ \ \ \ \}\n======\n\nThis\ approach\ would\ mean\ that\ the\ itcl::body\ command\ would\ not\ longer\ be\ needed.\n\n2.2\ \[\[info\ objects\]\ instead\ of\ itcl::find\n\nThis\ was\ discussed\ in\ section\ J,\ itcl::find\ is\ simply\ not\ useful\ enough\ \ to\ deserve\ its\ own\ global\ command.\ The\ functionality\ of\ find\ should\ be\ incorporated\ into\ the\ info\ command.\n\n\n'''Layer\ 3:'''\nChanges\ to\ the\ object\ declaration\ syntax\ (but\ not\ semantics)\ of\ classes.\n\nIn\ this\ section,\ we\ explore\ the\ impact\ of\ adding\ an\ \"instance\"\ modifier\ to\ the\ class\ declaration\ syntax.\ This\ addresses\ two\ issues.\ The\ first\ the\ variable\ command,\ as\ described\ in\ section\ K.\ The\ second\ is\ an\ objection\ to\ using\ proc\ instead\ of\ body,\ as\ described\ in\ Layer\ 2.\ Some\ folks\ felt\ that\ using\ the\ proc\ command\ to\ define\ the\ body\ of\ a\ \"method\"\ could\ be\ confusing.\n\n3.1\ instance\ modifier\n\nFor\ variables:\n\n======\n\ \ \ \ \ class\ Example\ \{\n\ \ \ \ \ \ \ instance\ variable\ _name\ \"bob\"\n\ \ \ \ \ \ \ variable\ _total\ 0\n\ \ \ \ \ \}\n======\n\nInstead\ of:\n\n======\n\ \ \ \ \ itcl::class\ Example\ \{\n\ \ \ \ \ \ \ variable\ _name\ \"bob\"\n\ \ \ \ \ \ \ common\ _total\ 0\n\ \ \ \ \ \}\n======\n\nFor\ methods:\n\n======\n\ \ \ \ \ class\ Example\ \{\n\ \ \ \ \ \ \ proc\ foo\ \{\}\n\ \ \ \ \ \ \ instance\ proc\ bar\ \{\}\n\ \ \ \ \ \}\n\n\ \ \ \ \ proc\ Example::foo\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ foo\"\n\ \ \ \ \ \}\n\n\ \ \ \ \ proc\ Example::bar\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ bar\"\n\ \ \ \ \ \}\n======\n\nInstead\ of:\n\n======\n\ \ \ \ \ itcl::class\ Example\ \{\n\ \ \ \ \ \ \ proc\ foo\ \{\}\n\ \ \ \ \ \ \ method\ bar\ \{\}\n\ \ \ \ \ \}\n\n\ \ \ \ \ itcl::body\ Example::foo\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ foo\"\n\ \ \ \ \ \}\n\n\ \ \ \ \ itcl::body\ Example::bar\ \{\}\ \{\n\ \ \ \ \ \ \ puts\ \"called\ bar\"\n\ \ \ \ \ \}\n======\n\nThis\ approach\ would\ solve\ the\ problem\ of\ incompatible\ variable\ commands.\ Using\ an\ \"instance\"\ modifier\ would\ mean\ that\ \"common\"\ and\ \"method\"\ would\ no\ longer\ be\ needed.\ That\ is\ a\ good\ thing\ in\ my\ book,\ \"instance\ variable\"\ is\ a\ lot\ more\ descriptive\ than\ \"common\".\n\n\n'''Layer\ 4:'''\nSemantic\ changes\ that\ would\ require\ some\ rewriting\ of\ effected\ code.\n\n\ \ \ 4.1\ Get\ rid\ of\ class\ procs\n\nMany\ of\ the\ problems\ mapping\ Itcl\ classes\ to\ Tcl\ namespaces\ seem\ to\ be\ related\ to\ class\ procs.\ Class\ procs\ are\ also\ cited\ as\ a\ reason\ that\ the\ proc\ command\ can\ not\ be\ used\ instead\ of\ the\ body\ command.\n\nWhen\ you\ get\ right\ down\ to\ it,\ class\ procs\ are\ simply\ incompatible\ with\ Tcl\ procs.\ They\ have\ different\ variable\ access\ defaults\ and\ class\ procs\ employ\ access\ control.\ Why\ should\ there\ be\ a\ distinction\ between\ procs\ defined\ in\ a\ namespace\ vs\ procs\ defined\ in\ a\ class\ body?\n\nI\ suggest\ the\ removal\ of\ the\ entire\ concept\ of\ class\ procs.\ Programmers\ would\ need\ to\ explicitly\ import\ namespace\ variables\ and\ there\ would\ be\ no\ access\ control,\ but\ Tcl\ programmers\ have\ been\ dealing\ with\ these\ issues\ for\ a\ long\ time.\ The\ benefit\ would\ be\ a\ significant\ simplification\ of\ the\ implementation,\ since\ folks\ would\ be\ using\ regular\ Tcl\ procs.\n\n'''Layer\ 5:'''\nLarge\ changes\ that\ would\ modify\ both\ the\ semantics\ and\ syntax\ of\ object\ use.\ These\ changes\ would\ not\ be\ backward\ compatible\ by\ any\ stretch\ of\ the\ imagination.\n\n5.1\ Don't\ use\ public\ variables\ as\ options!\n\nThe\ use\ of\ public\ variables\ as\ the\ means\ to\ specify\ object\ options\ was\ a\ mistake.\ Itk's\ custom\ option\ system\ is\ proof\ that\ Itcl\ declaration\ based\ option\ system\ does\ not\ scale\ well.\ There\ is\ no\ reason\ to\ re-invent\ the\ wheel\ here,\ we\ can\ simply\ add\ itk's\ option\ interface\ directly\ to\ Tcl.\ \ \ This\ solves\ many\ of\ the\ issues\ described\ in\ section\ G.\n\nThe\ first\ problem,\ is\ of\ course\ the\ command\ and\ variable\ names\ used\ by\ itk.\ One\ possible\ approach\ would\ be\ to\ use\ \"oo_option\"\ instead\ of\ \"itk_option\".\n\n======\n\ \ \ \ \ class\ HiThere\ \{\n\n\ \ \ \ \ \ \ oo_option\ define\ -command\ \{puts\ \"hi\"\}\n\n\ \ \ \ \ \ \ constructor\ \{\ args\ \}\ \{\n\ \ \ \ \ \ \ \ \ oo_option\ initialize\ \$args\n\n\ \ \ \ \ \ \ \ \ puts\ \"-command\ is\ \$oo_option(-command)\"\n\ \ \ \ \ \ \ \}\n\ \ \ \ \ \}\n======\n\nThis\ approach\ to\ option\ management\ would\ also\ remove\ the\ need\ for\ a\ itcl::body\ command.\ A\ configbody\ callback\ is\ really\ like\ a\ variable\ trace,\ why\ don't\ we\ leverage\ that?\ It\ would\ also\ be\ trivial\ to\ add\ support\ for\ read\ traces.\n\n======\n\ \ \ \ \ class\ HiThere\ \{\n\n\ \ \ \ \ \ \ oo_option\ define\ -command\ \{puts\ \"hi\"\}\n\n\ \ \ \ \ \ \ oo_option\ trace\ w\ -command\ \{\n\ \ \ \ \ \ \ \ \ \ \ puts\ \"wrote\ -command\ value\ is\ \\\"\$oo_option(-command)\\\"\"\n\ \ \ \ \ \ \ \}\n\n\ \ \ \ \ \ \ oo_option\ trace\ r\ -command\ \{\n\ \ \ \ \ \ \ \ \ \ \ puts\ \"read\ -command\ value\"\n\ \ \ \ \ \ \ \ \ \ \ return\ \$oo_option(-command)\n\ \ \ \ \ \ \ \}\n\n\ \ \ \ \ \ \ constructor\ \{\ args\ \}\ \{\n\ \ \ \ \ \ \ \ \ oo_option\ initialize\ \$args\n\ \ \ \ \ \ \ \}\n\ \ \ \ \ \}\n======\n\nClearly,\ a\ number\ of\ implementation\ details\ would\ need\ to\ be\ worked\ out.\ The\ general\ idea\ is\ the\ important\ thing\ here.\n\n\ \ \ 5.2\ Object\ aggregation\ support\n\nSection\ L\ outlined\ the\ need\ for\ object\ aggregation\ support.\ The\ question\ remains,\ how\ do\ we\ implement\ it?\ Why\ don't\ we\ use\ the\ \"component\"\ interface\ defined\ by\ itk.\ The\ command\ and\ variable\ named\ would\ need\ to\ be\ changed.\ Perhaps\ oo_component\ would\ work.\n\nHere\ is\ the\ example\ from\ section\ L,\ re-implemented\ using\ an\ oo_component\ style\ interface.\n\n======\n\ \ \ \ \ class\ Member1\ \{\}\n\ \ \ \ \ class\ Member2\ \{\}\n\n\ \ \ \ \ class\ Aggregate\ \{\n\n\ \ \ \ \ \ \ constructor\ \{\ \}\ \{\n\ \ \ \ \ \ \ \ \ \ \ oo_component\ add\ mem1\ \{\n\ \ \ \ \ \ \ \ \ \ \ \ \ Member1\ \$\{this\}_mem1\n\ \ \ \ \ \ \ \ \ \ \ \}\n\ \ \ \ \ \ \ \ \ \ \ oo_component\ add\ mem2\ \{\n\ \ \ \ \ \ \ \ \ \ \ \ \ Member2\ \$\{this\}_mem2\n\ \ \ \ \ \ \ \ \ \ \ \}\n\ \ \ \ \ \ \ \}\n\ \ \ \ \ \}\n======\n\nNote\ that\ component\ objects\ would\ be\ destroyed\ automatically\ when\ the\ containing\ object\ was\ destroyed.\n\n5.3\ Add\ access\ control\ to\ Tcl\n\nIncompatibility\ section\ D\ outlined\ many\ of\ the\ problems\ mapping\ Itcl's\ concept\ of\ access\ control\ to\ Tcl.\ The\ current\ \"half\ and\ half\"\ state\ of\ access\ control\ is\ a\ very\ bad\ thing,\ one\ possible\ solution\ would\ be\ to\ tightly\ integrate\ Itcl's\ access\ control\ rules\ into\ Tcl\ itself.\n\nThis\ would\ be\ a\ major\ overhaul,\ but\ it\ seems\ like\ it\ should\ be\ possible\ to\ do\ this\ in\ a\ backwards\ compatible\ way.\ The\ problem\ with\ this\ approach\ is\ that\ it\ makes\ Tcl\ much\ more\ complex.\ It\ would\ be\ hard\ to\ argue\ that\ \"Itcl\ integration\"\ is\ not\ a\ major\ undertaking\ if\ fundamental\ concepts\ like\ variable\ access\ and\ procedure\ invocation\ need\ to\ be\ re-implemented\ to\ support\ Itcl.\n\n5.4\ Remove\ access\ control\ entirely.\n\nThe\ other\ solution\ to\ the\ problems\ defined\ in\ section\ D\ is\ to\ simply\ yank\ all\ access\ protection\ from\ the\ OO\ system.\ This\ is\ not\ nearly\ as\ drastic\ as\ it\ first\ sounds.\n\nFear\ that\ \"out\ of\ control\ programmers\"\ mucking\ about\ in\ internal\ variables\ will\ cause\ software\ faults\ are\ not\ founded\ in\ reality.\ One\ can\ already\ access\ any\ Itcl\ variable\ with\ the\ help\ of\ the\ itcl::scope\ command.\n\nRemoval\ of\ access\ control\ for\ method\ invocations\ would\ mean\ that\ the\ itcl::code\ method\ would\ no\ longer\ be\ needed.\ You\ don't\ need\ to\ use\ the\ itcl::code\ method\ to\ subvert\ access\ control\ if\ it\ does\ not\ exist.\n\nNote\ that\ I\ am\ only\ talking\ about\ removing\ access\ control\ restrictions\ for\ methods\ invocations.\ I\ think\ the\ public,\ protected,\ and\ private\ modifiers\ should\ be\ retained.\ They\ provide\ good\ documentation\ as\ to\ the\ programmers\ intent.\ Variables\ would\ continue\ to\ make\ use\ of\ these\ modifiers\ to\ control\ which\ variables\ are\ automatically\ made\ accessible\ to\ an\ instance\ method.\n\nIf\ unintended\ method\ invocation\ was\ a\ problem,\ a\ simple\ naming\ convention\ be\ used.\ Tcl\ programmers\ have\ been\ using\ naming\ conventions\ to\ avoid\ command\ clashes\ for\ a\ very\ long\ time.\n\nOne\ serious\ problem\ would\ be\ the\ possibility\ of\ breaking\ existing\ code\ because\ of\ newly\ ambiguous\ method\ invocations.\n\n======\n\ \ \ \ \ itcl::class\ C1\ \{\ public\ method\ foo\ \{\}\ \{\}\ \}\n\ \ \ \ \ itcl::class\ C2\ \{\ private\ method\ foo\ \{\}\ \{\}\ \}\n\ \ \ \ \ itcl::class\ C3\ \{\ inherit\ C1\ C2\ \}\n\n\ \ \ \ \ C3\ c3\n\ \ \ \ \ c3\ foo\n======\n\nIn\ this\ case,\ the\ call\ to\ foo\ would\ be\ ambiguous\ if\ there\ were\ no\ access\ controls.\ One\ could\ argue\ that\ the\ public/protected/private\ keywords\ could\ be\ used\ to\ disambiguate\ this\ method\ invocation,\ but\ I\ am\ not\ sure\ how\ convincing\ that\ would\ be.\n\nRemoving\ access\ control\ for\ method\ invocation\ would\ be\ a\ big\ step,\ but\ it\ would\ significantly\ simplify\ the\ implementation\ of\ OO\ in\ Tcl.\n\n'''The\ net\ effect.'''\n\nAssuming\ each\ layer\ of\ change\ was\ implemented,\ the\nnewly\ integrated\ Tcl+OO\ system\ would\ add\ the\nfollowing\ global\ commands\ to\ Tcl.\n\n\ class\n\ destroy\n\ local\n\ scope\n\nThe\ following\ commands\ would\ defined\ only\nwithin\ a\ class\ body.\n\n\ constructor\n\ destructor\n\ inherit\n\ instance\n\ oo_option\n\ oo_component\n\ proc\n\ private\n\ protected\n\ public\n\nThat's\ it,\ let\ the\ flaming\ commence!\n----\n\[Chang\ Li\]:\ Agree\ 99%.\n----\n\[EMJ\]:\ NO\ -\ I'm\ not\ going\ to\ argue\ with\ any\ of\ the\ detail,\ it's\ the\ principle\ I\ don't\ like.\ \ The\ principle\ is\ called\ '''Feature\ Bloat''',\ and\ that\ is\ not\ in\ the\ spirit\ of\ TCL.\ \ How\ many\ people\ are\ already\ using\ old\ versions\ of\ TCL,\ not\ for\ compatibility\ or\ out\ of\ perversity,\ but\ because\ they\ are\ small\ enough?\n\nIf\ you\ want\ a\ feature\ in\ TCL,\ there\ is,\ or\ will\ be,\ and\ extension\ for\ it.\ \ Extensions\ are\ good,\ just\ pick\ the\ ones\ you\ need.\ \ If\ the\ users\ might\ not\ have\ them,\ build\ a\ \[starkit\]\ for\ them.\n\nIf\ something\ is\ going\ in\ the\ core,\ it\ should\ be:\n\n\ \ \ *\ Of\ benefit\ to\ almost\ everybody\n\n\ \ \ *\ Small\ enough\ (I\ know\ that's\ subjective!)\n----\n\[LV\]\ that's\ why\ the\ \[TIP\]\ that\ was\ approved\ instead\ proposes\ including\n\[itcl\]\ as\ just\ another\ \[extension\].\ \ The\ problem\ is\ that\ to\ do\ either\ will\ require\neffort\ on\ the\ part\ of\ someone\ to\ make\ the\ code\ build\ appropriately.\nThere\ was\ a\ posting\ on\ \[comp.lang.tcl\]\ by\ Donal\ in\ the\ past\ few\ months\nabout\ what\ the\ effort\ would\ be\ to\ finish\ up\ the\ itcl\ TIP.\ \ \n\nEven\ with\ all\ the\ noise\ about\ how\ ''desperate''\ programmers\ need\ OO,\ there\ still\ doesn't\nappear\ to\ be\ even\ one\ of\ these\ desperate\ people\ willing\ to\ work\ through\ the\ issues\nand\ get\ this\ done.\n\n----\n\[SRIV\]\ I've\ been\ using\ \[snit\]\ to\ create\ tcl\ types\ and\ tk\ widgets,\ not\ because\ I\ want\ an\ OO\ programming\ system,\ but\ because\ tcl/tk\ makes\ it\ too\ damn\ hard\ to\ create\ your\ own\ widgets!\ Maybe\ it\ was\ snit's\ easy\ to\ understand\ docs\ that\ enabled\ me.\ Regardless,\ until\ using\ snit,\ I\ never\ used\ any\ OO\ featured\ language.\ But,\ now\ I\ see\ a\ real\ need\ for\nit.\ I\ never\ tried\ Itcl,\ but\ if\ it\ can\ painlessly\ do\ all\ of\ what\ snit\ can\ do,\ and\ enable\ me\ to\ easily\ extend\ tcl/tk\nwith\ new\ or\ compound\ widgets,\ I\ think\ it\ would\ be\ a\ worth\ while\ addition.\ Until\ then,\ \"package\ require\ snit\"\ .\n\n\[DKF\]:\ At\ least\ some\ people\ claim\ that\ \[Snit\]\ makes\ it\ easier\ to\ create\ new\ widgets\ than\ \[Itcl\].\ \n----\n\[RS\]\ How\ is\ it\ hard\ to\ create\ \"your\ own\ widgets\"?\ I\ assume\ you\ mean\ \"megawidgets\"\ composed\ of\ stock\ widgets\ (\"in\ contrast\ to\ Megahertz\ and\ Megabytes,\ a\ megawidget\ isn't\ worth\ a\ million\ widgets\"...)\ Whenever\ I\ need\ some\ custom\ composition\ of\ widgets,\ I\ just\ code\n\n======\n\ proc\ myMega\ \{w\ args\}\ \{\n\ \ \ \ frame\ \$w\n\ \ \ \ thisComponent\ \$w.1\ ...\n\ \ \ \ thatComponent\ \$w.2\ ...\n\ \ \ \ ...\n\ \ \ \ eval\ pack\ \[winfo\ children\ \$w\]\ \;#\ or\ grid,\ or\ whatever\n\ \ \ \ set\ w\ \;#\ so\ the\ caller\ can\ reuse\ it\n\ \}\n======\n\nI\ think\ this\ \[simple\]\ approach\ beats\ worrying\ over\ complex\ frameworks,\ their\ documentation,\ their\ deployment,\ etc.\ But\ of\ course\ I\ also\ use\ \[BWidget\]\ at\ times\ :)\n----\n\[SRIV\]\ yes,\ for\ simple\ cases\ this\ is\ fine.\ In\ my\ case,\ Im\ writing\ a\ tk\ GUI\ builder,\ that\ needs\ to\nquery\ widgets\ for\ their\ options,\ handle\ methods,\ instances\ etc.\ In\ other\ words,\ I\ needed\ the\ megawidget\ to\ behave\ like\ a\ real\ widget\ in\ every\ way.\ Snit\ enabled\ that\ while\ simplifying\ every\ aspect\ \ of\ working\ with\ the\ megawidgets.\ In\ short\ order,\ I\ was\ cranking\ out\ widgets\ one\ after\ another,\ all\ with\ excellent\ results.\ For\ a\ novice\ widget\ builder\ like\ myself,\ snit\ made\ megawidget\ creation\ posible\ \ \ \ \nwith\ simplicity,\ clarity\ and\ speed.\ A\ facility\ that\ has\ long\ been\ lacking\ in\ the\ core.\ \n----\n\[LV\]\ I\ think\ that\ Sriv\ is\ talking\ about\ features\ that\ make\ a\ \[megawidget\]\ a\ megawidget\nrather\ than\ a\ proc\ that\ creates\ a\ complex\ widget.\n\nThe\ ability\ of\ the\ resulting\ creation\ to\ respond\ to\ \[introspection\],\ \nto\ be\ able\ to\ be\ trivially\ configured,\ to\ interact\ with\ the\ option\ndatabase,\ all\ result\ in\ a\ cleaner,\ easier\ to\ reuse\ widget.\n----\nSee\ also\ \[itcl\]\ and\ \[TIP\ #257:\ Object\ Orientation\ for\ Tcl\].\n\n<<categories>>\ Suggestions\ |\ TIP\ |\ Itcl} CALL {my revision {Integrating Itcl into the Tcl core}} CALL {::oo::Obj2992086 process revision/Integrating+Itcl+into+the+Tcl+core} CALL {::oo::Obj2992084 process}

-errorcode

NONE

-errorinfo

Unknow state transition: LINE -> END
    while executing
"error $msg"
    (class "::Wiki" method "render_wikit" line 6)
    invoked from within
"my render_$default_markup $N $C $mkup_rendering_engine"
    (class "::Wiki" method "render" line 8)
    invoked from within
"my render $name $C"
    (class "::Wiki" method "revision" line 31)
    invoked from within
"my revision $page"
    (class "::Wiki" method "process" line 56)
    invoked from within
"$server process [string trim $uri /]"

-errorline

4