home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / oop / macapp3 / 276 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  8.4 KB
  1. Path: sparky!uunet!olivea!apple!applelink.apple.com
  2. From: STRATA3D@AppleLink.Apple.COM (StrataVision, Gary Bringhurst,PRT)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Bedrock/CW/Camelot anyone?
  5. Message-ID: <725198190.7947011@AppleLink.Apple.COM>
  6. Date: 24 Dec 92 11:50:00 GMT
  7. Sender: usenet@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 169
  10.  
  11. Fellow MacApp castaways,
  12.  
  13. Merry Christmas and happy holidays!
  14.  
  15. Our company now has two interactive development environments in house for
  16. evaluation;  Component Workshop, which you all have heard about, and Camelot,
  17. which you may not yet be familiar with.
  18.  
  19. First, let me give some background information.  Camelot is a product of Wyvern
  20. Technologies Inc. of Ottawa Ontario Canada.  (If you want to reach them their
  21. phone number is 1-800-265-4368)  I am not affiliated with Wyvern in any way,
  22. other than having stopped by their booth at Comdex.  I have used Camelot 2.7 on
  23. the Macintosh and had a satisfying demo of it under Windows/NT.  It also runs
  24. under Windows 3.1 and OS/2 2.0.  Suggested retail for this development
  25. environment is $995, but introductory pricing is $749.  Applications developed
  26. with Camelot require no runtime license.
  27.  
  28. Camelot is still in beta form, but should ship by January.  It is refered to as
  29. version 2.7, but that applies more to the object model than the complete
  30. environment, which should probably be considered a version 1.0.  The version I
  31. saw demoed under Windows/NT appeared much more complete than the Mac version
  32. I'm playing with, so I assume that Windows support has been the top priority.
  33. Due to the underlying implementation of Camelot I expect that the Mac version
  34. will be just as robust as the windows version, although right now it is a
  35. little fragile.  Camelot and applications developed with Camelot can run on
  36. Windows 3.1, Windows/NT, OS/2 2.0, and Mac systems 6.x and 7.x without
  37. recompilation.
  38.  
  39. Now let me give you the good news/bad news (depending upon your perspective):
  40.  
  41. - Camelot includes an interface builder-like development environment, allowing
  42. nearly instantaneous turnaround while prototyping interfaces.  Attaching
  43. instance-specific methods to interface elements avoids the large number of
  44. classes normally created to support new behaviours.
  45.  
  46. - Camelot has defined a new language and object model that is neither C++,
  47. Eiffel, or SmallTalk.  It is a C-like language (called Fire) with a very
  48. sophisticated method dispatching mechanism.  Instance specific methods are
  49. supported, as is automatic delegation of methods from one object to another.
  50. Multiple inheritance is not provided, but is arguably not needed thanks to
  51. delegation.  Multi-threading tasks, asynchronous method calls and network
  52. distributed objects are also supported.  Full support for DDE and DLL's written
  53. in other languages (such as C) is included.  Here is an example method:
  54.  
  55.     #include "DCCDefinitions.D"
  56.  
  57.     #ifndef DCC
  58.     #   define DCC  5
  59.     #endif
  60.  
  61.     method open( arg integer ) returning string
  62.     {
  63.         name    string : initial value "DNX";
  64.         element object.dcc(ne); /* object of at least class dcc in module ne */
  65.  
  66.         if ( arg:assigned )
  67.         {
  68.             name := elements[ DCC, arg ].name;
  69.         }
  70.         if ( name:length >= 17 )
  71.         {
  72.             [ New(element) ConnectionAddFirstTo( self ) ];
  73.         }
  74.  
  75.         return ( name );
  76.     }
  77.  
  78. Note that a preprocessor is included.  The language also includes standard flow
  79. of control constructs and runtime feature access via the obj.<<"feature name">>
  80. construct, where the name is any string expression.
  81.  
  82. - A built-in source level debugger is included which is very similar to that
  83. available in Think C, with the additional ability to edit and run the code
  84. without restarting your program.
  85.  
  86. - Garbage collection is an integral part of the environment.
  87.  
  88. - Camelot supports the notion of a Module (much like Component Workshop) which
  89. eliminates name clashes when integrating independently developed code.
  90.  
  91. - Object repositories are used to store copies of object instances, which can
  92. then be re-instantiated.  This implies full object persistency.  This mechanism
  93. is used to save entire view hierarchies created in the interface builder for
  94. later instantiation or editing.  It is also how all of the tools within the
  95. environment are supplied, which makes the entire environment completely
  96. customizable, from the menu bars right down to the object browsers and
  97. inspectors.
  98.  
  99. - A new platform independent graphics model is supplied, along with a full
  100. collection of standard utility and GUI classes.
  101.  
  102. - Methods are compiled to a byte-code form for execution on any platform.
  103. These byte-code methods are then compiled to machine dependent code at run-time
  104. depending upon call frequency and other criteria.  Dispatch tables are also
  105. optimized where possible for the native platform.  A native code method
  106. dispatch is supposed to take somewhere around four instructions.  Comparing the
  107. performance of finished applications between Component Workshop and Camelot
  108. will be impossible until March or later when the extruder ships for Component
  109. Workshop.
  110.  
  111. There are numerous other features and aspects of the environment which I don't
  112. have the space to discuss here.  I have been evaluating beta software on the
  113. Mac which does not include native code generation, so I don't have any
  114. performance figures to throw around.  The environment itself seems a little
  115. zippier than Component Workshop and considerably more dynamic.  It is this
  116. underlying flexibility, along with the promise of native code generation and
  117. other optimizations aimed at efficiency, that make this multi-platform
  118. development environment so exciting.  It also seems to deliver portability
  119. which is still only a promise on the lips of Component Workshop and
  120. Symantec/Apple.
  121.  
  122.  
  123. Arguments against Camelot include:
  124.  
  125. - Its language is proprietary, and therefore a poor choice to standardize on,
  126. while Component Workshop is based on C++, the industry standard.
  127.  
  128. + Well, Component Workshop uses C++, NOT!  There is no preprocessor, and I defy
  129. anyone to extract their source from Component Workshop (not the extruded C
  130. files) and move to another development environment.  How will you replace the
  131. required garbage collector?  The bottom line - they both represent a gamble of
  132. approximately the same proportions.
  133.  
  134. - Relying on byte code interpretation of methods will result in a slow
  135. application.
  136.  
  137. + The native code optimization should remove any concern about this, since you
  138. have the option to save the native code with the application.  If it is run on
  139. another hardware platform this code is thrown away and new code is generated.
  140. You can also restrict your application to require a specific hardware host.
  141.  
  142.  
  143. Component Workshop worries me because of the unanswered questions revolving
  144. around the extruder. (How static do the applications become?  Do we lose all
  145. dynamic behaviour?)  I also worry about the implementation of external code
  146. support.  Does everyone realize that you have to relink Component Workshop with
  147. your code everytime your code changes?  And if you want internal users running
  148. development versions of an application, do they have to run a 20 meg partition
  149. CW session, or do we wait for an extrusion (probably a very lengthy process), a
  150. recompile and a relink for every internal release?  My rosy glasses have just
  151. gone a little pale.
  152.  
  153. Oh well, however all this works out, our plan is to keep our core application
  154. in standard C++, supplied in a DLL or shared library, and to write the
  155. interface in our chosen framework.  If our choice goes kerplunk down the line
  156. we can switch to another without too much trouble.  It seems that all
  157. development environments are headed towards a dynamic, garbage collecting,
  158. smalltalk-like environment anyway.  My guess is that it should take about two
  159. years to stabilize.  In the mean time, we can't wait.  An extruder in March
  160. (?), Windows 3.1 (but not NT) in the fall, or even an alpha BedRock at WWDC is
  161. just not enough soon enough, is it?
  162.  
  163. Please check out this new development option.  Let's discuss the merits and
  164. disadvantages of the different solutions headed our way.  I'm more than willing
  165. to share any findings, since I want to be using tools that will be supported
  166. down the road, and that means achieving critical mass.
  167.  
  168.  
  169. Sincerely,
  170.  
  171. Gary Bringhurst
  172. Strata Inc.
  173. AppleLink: STRATA3D
  174.  
  175.  
  176. P.S.  I guess this did sound like a commercial for Camelot after all.  To be
  177. fair, the 1.0 release of Component Workshop is more stable than the beta
  178. release of Camelot, but I don't expect that to remain true once Camelot ships.
  179.  
  180.