Camille and Marcus, thank you for your response. I thought something was
missing, so the testing of Slots will be shelved for now; however, while
it is in the planning stage, I would like to add some thoughts on
targets and deliverable products (applications).
I agree that most devices like the iPad and iPhone would not be suitable
for development, they should be targets for application development and
I would expand that list to include all devices, even micro-controllers.
Look at the development process for the iPad and iPhone, the programming
is done on a Mac using Xcode and testing is done first on the simulator
running on the Mac and latter on the actual device. I find the Xcode
environment inferior to Smalltalk's and by no stretch of the imagination
is Objective-C a good substitute for Smalltalk. I think that development
of application programs could be done far better with Smalltalk,
provided that some tools were added to Smalltalk. Why not have the view,
if it can be programmed in C then it can be programmed in Smalltalk.
I think that the application process should be viewed as a series of
steps culminating in the production of a product for sale or
distribution: develop and test the program logic, test using constraints
imposed by the target device, performance testing, test on the target
device, and package for sale or distribution. A good examples of the
second step where the constraints of the target is imposed are the word
size and floating-point precision differences found in the target. If
the development of the application is on a 64-bit computer then integer
and floating-point calculated must be simulated for targets with smaller
word size and for 32-bit floating-point or no floating-point processor.
Implicit in those steps is the notion a gradual typing, the first uses
the Smalltalk model to generically test the logic of the program, while
the final step would require a fully compiled executable for some of the
targets. I would argue that one reason that Smalltalk was not a
commercial success was that you could not provide a fully compiled
executable to the customer. The tools that the Smalltalk environment
provides makes it a very productive application development environment,
but of what use are they to the end user of the application, say a clerk
or a business executive: why should any of the development tools be in
the final product?
It is clear that Slots will be used in the enforcement of typing at the
instance variable level, but what about temporary variables? Can a
compiler (machine not bytecode) be developed if temporary variables are
not typed? Then there is the question of how to handle the elements of
heterogeneous collections.
I have more thoughts, but the above are related to Slots. Any comments?
bw
