initial commit: implements PastMeeting, including all abstract methods
inherited from the Meeting interface (I believe there is no way to do this
in a more elegant way); includes two constructors - one creates a new
PastMeetingImpl from scratch, the second takes a MeetingImpl and a String
as parameters, to convert a meeting that has occurred into a past meeting,
adding the String given to the notes about the meeting.
corrected the second construct (that takes a meeting as a param);
now expects any class that implements Meeting instead of specifically
MeetingImpl.
initial commit: implements FutureMeeting (including all abstract methods
inherited from Meeting interface; similar to PastMeetingImpl I know of no
simpler way around this, in any case it just involves a little
copy-pasta). Looking at all the separate meeting classes we have, my
first-pass solution for managing meeting IDs is going to be very messy at
best and liable to ID overloading/overwriting at worst. This should be
controlled centrally by the ContactManager itself.