Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!seunet!news2.swip.net!plug.news.pipex.net!pipex!tank.news.pipex.net!pipex!lyra.csx.cam.ac.uk!sunsite.doc.ic.ac.uk!qmw!orac.sunderland.ac.uk!i_mitchell_pc.sunderland.ac.uk!Ian.Mitchell From: Ian.Mitchell@sunderland.ac.uk (Ian Mitchell) Newsgroups: comp.object,comp.lang.beta,comp.lang.c++,comp.lang.eiffel,comp.lang.python,comp.lang.sather,comp.lang.smalltalk Subject: Re: Rapid Prototyping + statically-typed OOPLs? Date: Wed, 2 Aug 1995 18:10:29 Organization: University of Sunderland Lines: 69 Message-ID: References: <3v1vk1$bjp@newsbf02.news.aol.com> NNTP-Posting-Host: i_mitchell_pc.sunderland.ac.uk X-Newsreader: Trumpet for Windows [Version 1.0 Rev A] Xref: news.daimi.aau.dk comp.object:34705 comp.lang.beta:499 comp.lang.c++:132657 comp.lang.eiffel:9817 comp.lang.python:5319 comp.lang.sather:2043 comp.lang.smalltalk:25185 In article tmb@concerto.best.com writes: >From: tmb@concerto.best.com >Subject: Re: Rapid Prototyping + statically-typed OOPLs? >Date: 29 Jul 1995 23:36:52 GMT >In article Ian.Mitchell@sunderland.ac.uk (Ian Mitchell) writes: >| Smalltalk may indeed make C++ look incredibly verbose; this >| is not my point. My point is that C++ can be used for RP >| purposes because it is easy to extract a call tree for the >| methods [...] >It is? Care to demonstrate? As far as I can tell, determining who >calls who in a C++ program requires at least as much effort as a full >compiler front end. Yes, and variants on compiler front ends are widely available in the public domain for reuse. >Note that just looking for ".name(" and "->name(" tells you very >little about what code actually gets invoked. You need to know >whether "name" refers to a virtual or non-virtual member function. If >it's a non-virtual function, you need to know the type of the thing to >the left of the member operator. And then, of course, there are all >the binary operators that you won't catch at all without a full >syntactic analysis. And there are overloaded and template functions >and template specializations, which can make it very hard to figure >out what piece of code corresponds to a particular function call. I don't see why you need to determine the type of any services when extracting a call tree for a method, since the thread will go out of scope for that method when the service is invoked. You don't care whether a function is overloaded or polymorphic for the same reason. The need for a full syntactic analysis to catch binary operators is a good point, but if the overloading of an operator is really within the remit of the rapid prototype, would this not be modelled as an implicit service? I don't see why an analyst want an operator to feature in a call tree for a rapid prototype. >In any case, I really don't see what a call tree has to do with RP. I >generally need call trees only when I inherit some poorly structured >large program. > Thomas. Call trees are used when moving between problem space and solution space in rapid prototyping. For example, if a particular prototype has been used for shadow running, and the users have verified that particular iteration, the call tree can be extracted and the model migrated back to an implementation independent format. If you're interested, I have a paper about this in the forthcoming OO & ER'95 conference in Australia. Regards, Ian Mitchell ----------------------------------------------------------------- Ian Mitchell Ian.Mitchell@sunderland.ac.uk osiris.sund.ac.uk/research/canopus/mitchell/rpl.html ----------------------------------------------------------------- sic biscuitus disintegrat -----------------------------------------------------------------