OK, this is basically a request for someone to implement Exception and enough of its descendants (e.g., Error, SelectorException, and SubclassResponsibility)... such that Object (Lee B's baby) can call it, a la Pharo:
Object>>subclassResponsibility SubclassResponsibility signalFor: thisContext sender selector
Right? If so, I'll tackle it. I'm also keen to work on the collections classes and protocols, including various Streams-related classes. But this seems very useful for starters.
- Bob |
OK, I added Exception and related children to the OBJECTS-AND-PROTOCOLS doc based on the Pharo 1.3 list of 'Kernel-Exceptions', and cherry picked Exception, Error, SelectorException, and SubclassResponsibility for adoption (will adopt others as necessary). I've committed this change to my fork of redline-smalltalk at github, and issued a pull request.
I feel like a real member of the project now. :) - Bob
On Fri, Dec 23, 2011 at 11:32 AM, Robert Calco <[hidden email]> wrote: OK, this is basically a request for someone to implement Exception and enough of its descendants (e.g., Error, SelectorException, and SubclassResponsibility)... such that Object (Lee B's baby) can call it, a la Pharo: |
Merged. We can work out the details of if we want all or not later. On Fri, Dec 23, 2011 at 6:48 AM, Robert Calco <[hidden email]> wrote: OK, I added Exception and related children to the OBJECTS-AND-PROTOCOLS doc based on the Pharo 1.3 list of 'Kernel-Exceptions', and cherry picked Exception, Error, SelectorException, and SubclassResponsibility for adoption (will adopt others as necessary). I've committed this change to my fork of redline-smalltalk at github, and issued a pull request. |
On Fri, Dec 23, 2011 at 11:52 AM, Sean Allen <[hidden email]> wrote:
- Bob |
In reply to this post by bobcalco
Re Streams: I'm actually dipping in to them a bit (sorry for the pun) in order to try to implement Object>printString.
|
...and I don't think I should take ownership of the Stream classes I'm editing. I think we should be allowed to edit classes outside those we "own", right? The owner can be responsible for merging any conflicts, right?
|
On Fri, Dec 23, 2011 at 10:13 AM, Lee Breisacher <[hidden email]> wrote: ...and I don't think I should take ownership of the Stream classes I'm editing. I think we should be allowed to edit classes outside those we "own", right? The owner can be responsible for merging any conflicts, right? Quite reasonable.
|
In reply to this post by bobcalco
Brilliant effort bob!
On Friday, December 23, 2011, Robert Calco <[hidden email]> wrote: > OK, I added Exception and related children to the OBJECTS-AND-PROTOCOLS doc based on the Pharo 1.3 list of 'Kernel-Exceptions', and cherry picked Exception, Error, SelectorException, and SubclassResponsibility for adoption (will adopt others as necessary). I've committed this change to my fork of redline-smalltalk at github, and issued a pull request. > I feel like a real member of the project now. :) > - Bob > > On Fri, Dec 23, 2011 at 11:32 AM, Robert Calco <[hidden email]> wrote: >> >> OK, this is basically a request for someone to implement Exception and enough of its descendants (e.g., Error, SelectorException, and SubclassResponsibility)... such that Object (Lee B's baby) can call it, a la Pharo: >> Object>>subclassResponsibility >> SubclassResponsibility signalFor: thisContext sender selector >> Right? >> If so, I'll tackle it. >> I'm also keen to work on the collections classes and protocols, including various Streams-related classes. >> But this seems very useful for starters. >> >> - Bob >> >> On Fri, Dec 23, 2011 at 9:27 AM, Sean Allen <[hidden email]> wrote: >>> >>> If anyone wants to have at it: >>> https://github.com/redline-smalltalk/redline-smalltalk/issues/67 >>> >> > > |
Free forum by Nabble | Edit this page |