The Sport BOF

490 views

Published on

The Sport BOF. ESUG 2007, Lugano

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
490
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Sport BOF

  1. 1. The Sport BOF
  2. 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. 3. Dialects with Sport ● VisualWorks ● GemStone ● Squeak ● Dolphin ● Visual Smalltalk Enterprise ● Visual Age (work in progress) ● Planned for GNU Smalltalk and ST/X
  4. 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. 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. 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. 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. 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. 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. 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.
  11. 11. Discussion

×