Your SlideShare is downloading. ×
The Sport BOF
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The Sport BOF

358
views

Published on

The Sport BOF. ESUG 2007, Lugano

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
358
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. The Sport BOF
  • 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.
  • 11. Discussion

×