To Do

There are several items that need to be worked on to make a complete Smalltalk for .NET implementation. Here's an incomplete list of items. If you would like to work on an item, please send us email.

  • Add ability to subclass .NET classes. Currently, all classes must be subclasses of a special root class so we can implement doesNotUnderstand: properly. Instead of making a special root class, we can implement a special root interface with all of the appropriate methods.
  • Add ability to define methods that don't have #Smalltalk types and #Smalltalk names. For example, suppose you with to export the #at:put: method in Array. Currently, that method is compiled as #at:put:, but that isn't a valid name for languages like C#. Furthermore, that method takes two Smalltalk objects, not an integer and an object.
  • Use type inferencing to eliminate some SmallInteger objects. For example, if we have the following code, "1 to: 1000 do: [:i | self foo]", that creates 1000 SmallInteger objects. However, we don't need the full blown objects and can use int32 instead. This will speed up some integer calculations. In addition to eliminating some SmallInteger objects, we can also eliminate float objects, compile time type checks, etc.
  • Build a bigger class library. The current class library does not have support for much more than the ANSI standard. To be a proper Smalltalk, we need support for databases, GUI's, etc. Many of these items are in the .NET class library so we can use their implementations, but we may want to make wrappers around their functionality.
  • Build development tools. If you think vi or emacs is the best development environment, then you'll like the current suite of development tools. However, there are some of us that want refactoring support for our development tools.
  • Optimize the code. Currently, there hasn't been any optimization on the #Smalltalk code. The compiler takes too much time and memory to compile a simple program. Some of the memory appears to be outside the compiler's control, but there should be some optimizations to make it run faster.
  • Improve the compiler's error messages. Some errors give the user no clue of what failed or how to fix it. This is not good. We need to add more specific error messages.
  • Fix bugs (isn't this on every one's list).

 

Contact Us

  • 7 Florida Drive
    Urbana, IL 61801
  • 1-217-344-4847
  • info@refactory.com

About Us

The Refactory, Inc. aims to improve the quality of life for those involved with all aspects of software development. The Refactory bases our mentoring and consultation on proven practices backed by industry leading research.

Copyright © 1998 - Present, All Rights Reserved.