Newsgroups: comp.lang.perl,comp.lang.scheme,gnu.misc.discuss,comp.lang.tcl
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!godot.cc.duq.edu!news.duke.edu!convex!cs.utexas.edu!howland.reston.ans.net!EU.net!uknet!comlab.ox.ac.uk!sable.ox.ac.uk!mbeattie
From: mbeattie@sable.ox.ac.uk (Malcolm Beattie)
Subject: Re: Why you should not use Tcl
Message-ID: <1994Oct2.125540.4661@inca.comlab.ox.ac.uk>
Organization: Oxford University Computing Service, 13 Banbury Rd, Oxford, UK
References: <9409232314.AA29957@mole.gnu.ai.mit.edu> <DJOHNSON.94Sep27161511@seuss.ucsd.edu> <36eshf$cno@aurns1.aur.alcatel.com> <36fh44$f38@csnews.cs.colorado.edu>
Date: Sun, 2 Oct 94 12:55:39 BST
Lines: 80
Xref: glinda.oz.cs.cmu.edu comp.lang.perl:35398 comp.lang.scheme:10192 gnu.misc.discuss:18645 comp.lang.tcl:19790

In article <36fh44$f38@csnews.cs.colorado.edu>,
Tom Christiansen  <tchrist@mox.perl.com> wrote:
>:-> In comp.lang.tcl, throopw%sheol.uucp@dg-rtp.dg.com (Wayne Throop) writes:
>:   STk
>:
>:       (define f (make <Frame>))
>:       (define l (make <Label>  
>:                       :parent f 
>:                       :text "A simple demo written in STklos"))
>:
>:   tkperl
>:
>:       $f = Frame::new($path);
>:       $l = Label::new($f, "-text" => "A simple demo written in tkperl");
>:
>:   tcl/tk
>:
>:       frame .f
>:       label .f.l -text "A simple demo written in tcl/tk"
>
>Actually, that's more noise characters in the perl than you need by a long shot.
>That's because
>
>    object->method(args)
>    CLASS::method(args)
>
>May always be expressed
>    
>    method object args;
>    method CLASS args;
>
>This reduces our perl version to:
>
>    $f = new Frame $path;
>    $l = new Label $f, "-text" => "A simple demo written in tkperl";
>
>Which is considerably less busy, wouldn't you agree?  
>
>One of the results of Larry's attendance at a REXX symposium while
>he was writing perl's object system was an appreciation for REXXers
>dislike for line noise all over their code. :-)

[A partial version of this posting may just have escaped, sorry.]

That's not quite right, unfortunately. The two equivalent versions
    method CLASS args
    CLASS->method args
correspond to the version
    CLASS:method CLASS, args
(in other words, the subroutine itself gets passed an extra first argument
in the first two forms. This helps inherited method from determining which
class the call was actually for). tkperl was around before the new-fangled
versions "method CLASS args" and "CLASS->method args" were invented
(perl5alpha3 perhaps?). tkperl widget code already copes with both Tk/Tcl
pathnames and having a parent widget and I haven't added the extra
checks for a classname argument prepended too. It will get done. Since
I've been on leave this week, I've been doing some work on tkperl for
things like transparent remote processing via "proxy objects". These
are objects which can be treated as local objects but any method calls
get sent transparently to some remote process for execution. The Proxy
class itself if transport-independent (the Proxy::Tk derived class
uses the same "append to property" transport as Tk/Tcl "send").
Further, almost all data types (*) including objects and references to
lists, associative arrays and scalars get transparently frozen,
sent across to the remote process and thawed there so the programmer
can use subroutines and methods without bothering to encode complicated
data structures or worry about where they will be executed. A little
emacs server process similar to the "emacsserver" that handles
emacsclient requests means that a tkperl program can execute elisp
in a remote emacs process on the same X display. The next step is
thawing the lisp structures on the emacs side in such a way that
perl associative arrays, lists and references become their elisp
equivalents automatically.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk> (note new address)
Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee
