2. Sport
â A Smalltalk portability library API
â Allows identical source code to work with many
Smalltalk dialects
â Support for
â Sockets
â Files
â Exceptions
â Date and Time
â other stuff
3. Dialects with Sport
â VisualWorks
â GemStone
â Squeak
â Dolphin
â Visual Smalltalk Enterprise
â Visual Age (work in progress)
â Planned for GNU Smalltalk and ST/X
4. How to âportâ Sport
â Choose a Sport based library you want to use
â You need to be motivated
â I recommend the Hyper or PostgreSQL libs
â Choose a Sport-free dialect
â Have an existing Sport for reference (e.g. VW)
â Write your local Sport:
â Try to run the library and watch it crash
â Implement the missing bits of Sport
â try again
â There are some SUnit tests too
5. How will Sport evolve?
â Dialect inconsistency will cause Sport to grow
â ANSI standardisation (and implementation) will
cause Sport to shrink
â At any moment Sport should be as small as
possible, but no smaller
â The goal is to have Sport go away because the
dialects all implement a comprehensive ANSI
standard
6. Managing Sport evolution
â Two kinds of change:
â Extend the API (does not break existing code)
â Refactor the API (DOES break existing code)
â Extending is OK, but make sure that other
(target) Sport implementations agree.
â Refactoring should be discussed, planned and
infrequent
7. Why refactor?
â As we live with Sport and work towards ANSI
standardisation we may wish to have âbetterâ
structures for sockets, files etc.
â Noooooo!
â I don't want my library to be broken!
â I don't need no stinkin' new version!
â I want to use libraries that rely on different versions
of the Sport API in the same image at the same
time. Help!
8. API versions
â API versioning will let us have new API versions
without breaking existing code.
â Each version has a name and a class prefix...
â The names will be A,B,C etc (e.g. SportD)
â The prefixes will be Sp, Spb, Spc etc.
â The first version of Sport is special because:
â Not designed (It Evolved)
â Not documented
â Name/Prefix is âSportâ / âSpâ
â Call it âSport(A)â to be clear in docs
9. ANSI
â Important that the ANSI process is restarted
â The process should indeed be a process
â Not a one-off
â Regular deliveries (every 18 months?)
â Community defined priorities
â Sport is a tool for the ANSI process
â Testing ideas
â Setting priorities
10. Summary
â Sport smooths dialect inconsistency
â Sport is a dirty fix. ANSI should fix the problem.
â The Sport API will change, but with API
versioning should mean nothing breaks
â Documented on the OpenSkills wiki.
â http://wiki.openskills.org
â See the wiki for the location of a Sport
implementation for your dialect.