The Inbox: Kernel-fbs.736.mcz
Locked
 
|
Frank Shearar uploaded a new version of Kernel to project The Inbox:
http://source.squeak.org/inbox/Kernel-fbs.736.mcz ==================== Summary ==================== Name: Kernel-fbs.736 Author: fbs Time: 30 January 2013, 8:04:08.926 pm UUID: 1d99c937-4c68-475c-987b-2990c8040c29 Ancestors: Kernel-fbs.735 Rename NotImplemented errors in line with conventions 2 of 3. =============== Diff against Kernel-fbs.735 =============== Item was changed: ----- Method: Object>>shouldBeImplemented (in category 'error handling') ----- shouldBeImplemented "Announce that this message should be implemented" + ^ NotImplemented signal: ('{1} or a superclass should implement {2}' format: {self className. thisContext sender selector})! - ^ NotImplementedError signal: ('{1} or a superclass should implement {2}' format: {self className. thisContext sender selector})! Item was changed: ----- Method: Object>>shouldNotImplement (in category 'error handling') ----- shouldNotImplement "Announce that, although the receiver inherits this message, it should not implement it." + NotImplemented signal: ('{1} is not a message appropriate for a {2}' format: {thisContext sender selector. self className}).! - NotImplementedError signal: ('{1} is not a message appropriate for a {2}' format: {thisContext sender selector. self className}).! Item was changed: ----- Method: Object>>subclassResponsibility (in category 'error handling') ----- subclassResponsibility "This message sets up a framework for the behavior of the class' subclasses. Announce that the subclass should have implemented this message." + ^ SubclassResponsibility - ^ SubclassResponsibilityError signal: ('My {1} subclass should have overridden {2}' format: {self className. thisContext sender selector}).! |
Re: The Inbox: Kernel-fbs.736.mcz
|
|
On 30 January 2013 20:04, <[hidden email]> wrote:
> Frank Shearar uploaded a new version of Kernel to project The Inbox: > http://source.squeak.org/inbox/Kernel-fbs.736.mcz > > ==================== Summary ==================== > > Name: Kernel-fbs.736 > Author: fbs > Time: 30 January 2013, 8:04:08.926 pm > UUID: 1d99c937-4c68-475c-987b-2990c8040c29 > Ancestors: Kernel-fbs.735 > > Rename NotImplemented errors in line with conventions 2 of 3. > > =============== Diff against Kernel-fbs.735 =============== If folks are happy with what I've got, I'd like to make one more change, and remove NotYetImplemented>>#defaultAction. This will make this message send open up a Debugger. Then I just need to tweak the Debugger to show the Create button. If people think that's sensible I'll make the change and resubmit, clearing out obsolete Inbox ancestors to show a more complete diff. frank |
|
|
Pardon my ignorance, but your commit message mentions "conventions 2 of 3". What conventions are you speaking of?
On Thu, Jan 31, 2013 at 2:59 PM, Frank Shearar <[hidden email]> wrote:
|
Re: The Inbox: Kernel-fbs.736.mcz
|
|
A missing semicolon there! The convention is to not have 'Error' in the name of an Error; (<-- occasionally important punctuation mark ) it's commit 2 of 3. frank
|
Re: The Inbox: Kernel-fbs.736.mcz
|
|
In reply to this post by Frank Shearar-3
On 31 January 2013 22:59, Frank Shearar <[hidden email]> wrote:
> On 30 January 2013 20:04, <[hidden email]> wrote: >> Frank Shearar uploaded a new version of Kernel to project The Inbox: >> http://source.squeak.org/inbox/Kernel-fbs.736.mcz >> >> ==================== Summary ==================== >> >> Name: Kernel-fbs.736 >> Author: fbs >> Time: 30 January 2013, 8:04:08.926 pm >> UUID: 1d99c937-4c68-475c-987b-2990c8040c29 >> Ancestors: Kernel-fbs.735 >> >> Rename NotImplemented errors in line with conventions 2 of 3. >> >> =============== Diff against Kernel-fbs.735 =============== > > If folks are happy with what I've got, I'd like to make one more > change, and remove NotYetImplemented>>#defaultAction. This will make > this message send open up a Debugger. Then I just need to tweak the > Debugger to show the Create button. > > If people think that's sensible I'll make the change and resubmit, > clearing out obsolete Inbox ancestors to show a more complete diff. Actually, I'm going to hold off on touching NotYetImplemented. I think it's a good idea to remove the default action, but it and #shouldBeImplemented have a wrinkle that I can't see right now how to fix. Let's say you have Bar >> #ff [ self notYetImplemented ]. You evaluate `Bar new ff` and the Debugger pops up, asking if you want to create that method. You enter the desired behaviour - `^ 1` - and accept. The stack now looks like this: Bar >> #ff (containing `^ 1`) Bar >> #ff (containing `self notYetImplemented`) <the topmost frame of the rest of the stack> <the rest of the stack, ending in a DoIt> The topmost context returns, and _retriggers_ the exception. Instead, we should _discard_ the `self notYetImplemented` stack frame and have the new implementation return its result to <the topmost frame of the rest of the stack>. It's probably not even hard, but my brain's a big mushy. So instead I'd like to merge what I have, and add as a separate enhancement * removing NotYetImplemented >> #defaultAction * returning to the sender sender context, <the topmost frame of the rest of the stack>. This latter step should also avoid the problem of people not writing their stubs as `^ self subclassResponsibility`, which prevents seamlessly progressing with one's computation. (If you don't say `^` then your new result-returning implementation returns its result to the non-`^` stub/marker context, which returns self.) I want the experience of implementing missing functionality to be almost like rewriting history - "we have always had this implementation of this message". (To be read in the same voice as "We have always been at war with Eurasia.") frank |
Re: The Inbox: Kernel-fbs.736.mcz
|
|
On Sat, Feb 2, 2013 at 2:36 PM, Frank Shearar <[hidden email]> wrote: On 31 January 2013 22:59, Frank Shearar <[hidden email]> wrote: currentContext privSender: currentContext sender sender or currentContext swapSender: currentContext sender sender
best, Eliot
|
Re: The Inbox: Kernel-fbs.736.mcz
|
|
On 4 February 2013 22:12, Eliot Miranda <[hidden email]> wrote:
> > > On Sat, Feb 2, 2013 at 2:36 PM, Frank Shearar <[hidden email]> > wrote: >> >> On 31 January 2013 22:59, Frank Shearar <[hidden email]> wrote: >> > On 30 January 2013 20:04, <[hidden email]> wrote: >> >> Frank Shearar uploaded a new version of Kernel to project The Inbox: >> >> http://source.squeak.org/inbox/Kernel-fbs.736.mcz >> >> >> >> ==================== Summary ==================== >> >> >> >> Name: Kernel-fbs.736 >> >> Author: fbs >> >> Time: 30 January 2013, 8:04:08.926 pm >> >> UUID: 1d99c937-4c68-475c-987b-2990c8040c29 >> >> Ancestors: Kernel-fbs.735 >> >> >> >> Rename NotImplemented errors in line with conventions 2 of 3. >> >> >> >> =============== Diff against Kernel-fbs.735 =============== >> > >> > If folks are happy with what I've got, I'd like to make one more >> > change, and remove NotYetImplemented>>#defaultAction. This will make >> > this message send open up a Debugger. Then I just need to tweak the >> > Debugger to show the Create button. >> > >> > If people think that's sensible I'll make the change and resubmit, >> > clearing out obsolete Inbox ancestors to show a more complete diff. >> >> Actually, I'm going to hold off on touching NotYetImplemented. I think >> it's a good idea to remove the default action, but it and >> #shouldBeImplemented have a wrinkle that I can't see right now how to >> fix. >> >> Let's say you have Bar >> #ff [ self notYetImplemented ]. You evaluate >> `Bar new ff` and the Debugger pops up, asking if you want to create >> that method. You enter the desired behaviour - `^ 1` - and accept. The >> stack now looks like this: >> >> Bar >> #ff (containing `^ 1`) >> Bar >> #ff (containing `self notYetImplemented`) >> <the topmost frame of the rest of the stack> >> <the rest of the stack, ending in a DoIt> >> >> The topmost context returns, and _retriggers_ the exception. Instead, >> we should _discard_ the `self notYetImplemented` stack frame and have >> the new implementation return its result to <the topmost frame of the >> rest of the stack>. >> >> It's probably not even hard, but my brain's a big mushy. > > > currentContext privSender: currentContext sender sender > or > currentContext swapSender: currentContext sender sender Yep yep: in Debugger >> implement:inClass:category: this looks to do the trick: <stuff> "Snip out of the call stack the context that raised the debugger. - the #notYetImplemented send, for example." self selectedContext privSender: self selectedContext sender sender. self resetContext: self selectedContext. self debug. Thanks for the tip! (I've done enough stack hacking that I should have remembered this stuff. Sad times!) frank >> So instead I'd like to merge what I have, and add as a separate >> enhancement >> * removing NotYetImplemented >> #defaultAction >> * returning to the sender sender context, <the topmost frame of the >> rest of the stack>. >> >> This latter step should also avoid the problem of people not writing >> their stubs as `^ self subclassResponsibility`, which prevents >> seamlessly progressing with one's computation. (If you don't say `^` >> then your new result-returning implementation returns its result to >> the non-`^` stub/marker context, which returns self.) >> >> I want the experience of implementing missing functionality to be >> almost like rewriting history - "we have always had this >> implementation of this message". (To be read in the same voice as "We >> have always been at war with Eurasia.") >> >> frank >> > > > > -- > best, > Eliot > > > |
Re: The Inbox: Kernel-fbs.736.mcz
|
|
On Tue, Feb 5, 2013 at 2:58 PM, Frank Shearar <[hidden email]> wrote:
don't be hard on yourself. chops like these have to be used regularly. and look, they came back! :)
best, Eliot
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |