smb@data.com (Steven M. Boker) (03/21/91)
In article <CNH5730.91Mar20114004@maraba.tamu.edu> cnh5730@maraba.tamu.edu writes: >In article <1991Mar20.165430.2364@data.com> smb@data.com (Steven M. Boker) writes: > Those at NeXT who > are reading this should take note. Implementing Ronalds idea would > be a boon to the more-than-casual developer. > >Why not write an IBdocument.app and implement Ronald's idea your self? >Your app could interface with IB seamlessly if you implement the app using >NeXT's "services" paradigm. The basic problem with a third party IB scripting language is that it doesn't have the "standards" power that a release from NeXT would have. I agree that if NeXT decides that it has no intention of producing such a .nib scripter, a third party would have a hot product here. However, any release from NeXT would blow a third party away. Its a good idea, but a dangerous one from an investment standpoint for a third party developer. Steve. -- #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====# # Steve Boker # En Vino Kaos # # smb@data.com # En Kaos Veritas # #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
mfi@serc.cis.ufl.edu (Mark Interrante) (03/21/91)
In article <CNH5730.91Mar20114004@maraba.tamu.edu> cnh5730@maraba.tamu.edu writes: >In article <1991Mar20.165430.2364@data.com> smb@data.com (Steven M. Boker) writes: > Those at NeXT who > are reading this should take note. Implementing Ronalds idea would > be a boon to the more-than-casual developer. > >Why not write an IBdocument.app and implement Ronald's idea your self? >Your app could interface with IB seamlessly if you implement the app using >NeXT's "services" paradigm. I am more interested in what other developers think should be included in upcoming versions of IB. It seems that additional interface/data structure classes can be easily incorporated into IB so that is no longer an issue for IB-only development. Possible areas: 1. configuration support tools (multiuser) 2. an integrated graphical compiler/debugging tools. (ala mac/PC tools) of course this need not be part of IB per se. 3. I would like the ability to double click on just about anything in IB and have it open up or at least have an inspector popup. 4. ? This is one tool that NeXT has the lead in, what do others want included to help maintain that lead? ----------------------------------------------------------------------------- mark Interrante Software Engineering Research Center mfi@beach.cis.ufl.edu CIS Department, University of Florida 32611 ----------------------------------------------------------------------------- Quote from a west Texas farmer "status quo is Latin for the mess we're in."
smb@data.com (Steven M. Boker) (03/22/91)
In article <27533@uflorida.cis.ufl.EDU> mfi@serc.cis.ufl.edu (Mark Interrante) writes: > >I am more interested in what other developers think should be included >in upcoming versions of IB. It seems that additional interface/data structure >classes can be easily incorporated into IB so that is no longer an >issue for IB-only development. > >Possible areas: > >1. configuration support tools (multiuser) > >2. an integrated graphical compiler/debugging tools. (ala mac/PC >tools) of course this need not be part of IB per se. > >3. I would like the ability to double click on just about anything in >IB and have it open up or at least have an inspector popup. > >4. ? > >This is one tool that NeXT has the lead in, what do others want >included to help maintain that lead? I don't have any earthshaking suggestions, but I'd like to keep this ball rolling. Mark and I seem to have a common interest here. 4. How about an easier way to track down all of the inherited methods of a class? I am forever looking up ObscureClassDefinition to find that it inherits from AnotherObscureClass which inherits from StillAnotherObscureClass. After alot of mucking about, I've more or less learned them, but a class documentor which read all of the inherited (and overridden) methods and dynamically produced one .rtf file with the union of the class and its inherited methods and variables would be a boon. Here is one area where on-line documentation could really shine. Override a method and the documentation file dynamically rebuilds itself to reflect the new class definition. Steve. -- #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====# # Steve Boker # En Vino Kaos # # smb@data.com # En Kaos Veritas # #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
rca@cs.brown.edu (Ronald C.F. Antony) (03/25/91)
In article <27533@uflorida.cis.ufl.EDU> mfi@serc.cis.ufl.edu (Mark Interrante) writes: >I am more interested in what other developers think should be included >in upcoming versions of IB. It seems that additional interface/data structure >classes can be easily incorporated into IB so that is no longer an >issue for IB-only development. > >Possible areas: > >1. configuration support tools (multiuser) > >2. an integrated graphical compiler/debugging tools. (ala mac/PC >tools) of course this need not be part of IB per se. > >3. I would like the ability to double click on just about anything in >IB and have it open up or at least have an inspector popup. > >4. ? I think NeXT should have a look at Saber-C++ and Brown's Field environment. DEC e.g. licensed Field. (if you use it non commercially, it is available for free from Brown). For those that don't know what Field is, here a short abstract: Field is basically a message based glue that lets work together many of the Unix software tool. Some of them are also extended to do more than the basic version. This means you have a syntax sensitive editor that checks your grammar, thus resolving many problems before you do a compile. Then you have tools that let you graphically display complex data structures like e.g. trees. There are also graphical interfaces to make, x-ref tools etc. Since the whole thing is message based, it should be relatively easy to add other tools, use alternative editors etc. Field supports as of now, C, C++ and Pascal. So Objective-C support would have to added as well as an NextStep interface. In any case, it could be inspiring for the NeXT people to have a look at it, even more now that DEC will sell that as a product. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet