On Sep 30, 2011, at 3:40 PM, Bob Nystrom wrote: > > > On Fri, Sep 30, 2011 at 3:17 PM, Allen Wirfs-Brock <[email protected]> > wrote: > I'd argue that my pattern also supports #5 as IDE's can recognize the > pattern. An imperative class definition of all that most Smalltalk > implementations every had and they generally had fine IDEs. > > I'm not a Smalltalker, but I thought Smalltalk IDEs were image-based and > worked on the objects directly live in memory. At that point, it didn't > matter how you generated a class: from text, imperatively, by PEEKing and > POKEing bits in memory.
Not enterprise class Smalltalk IDE's such as Digitalk's Team/V or IBM/OTI Envy Developer. They did comprehensive analysis of Smalltalk source code before loading it into the image. This enabled conflict detections, version diff'ing, browsing/editing of unloaded class definitions, etc. I can speak definitively about Team/V as I was its architect. In processed source code into an internal object model (essentially a attributed AST) and this is what the tools operated upon, not the actual runtime representation of the program (well, there were versions of those models that could reflect upon the runtime structure). Building the models from source code included recognizing imperative patterns used to define classes. > > That isn't true of most IDEs today that are just working on the program text > itself. With today's editors, the textual format matters. (We might rightly > lament that fact, but it does seem to be the field we've got to play on right > now.) Some might argue whether this is a step forward or not (personally, I think a stable source code representation is important). However, it doesn't say anything about the feasibility of tool recognizing usage patterns. In fact, isn't that exactly what refactoring tools and code quality analyzers do? Allen >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
