> On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman <b...@openinworld.com> wrote: >> >> Just curious what the magic numbers here relate to... >> and can they be factored out to a meaningful method name? >> >> Context>>gtInspectorVariableValuePairs >> "This is a helper method that returns a collection of >> variable_name -> value >> for the current object. >> Subclasses can override it to specialize what appears in the variables >> presentation" >> | bindings | >> bindings := OrderedCollection new. >> 1 to: (self basicSize min: 21) do: [ :index | >> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt: >> index)) ]. >> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self >> haltIf: [ index = 99 ]." >> bindings add: (index "asString" -> (self basicAt: index)) ]. >> bindings >> addAll: ((self class allSlots >> collect: [ :slot | slot name -> (slot read: self) ]) sort >> asOrderedCollection). >> ^ bindings >> >> >> cheers -ben > >
On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis <chisvasileand...@gmail.com> wrote: > Yes these numbers should be refactored > For collections only the first and the last 21 elements are displayed in the > Raw view. Don't remember why 21. > > Cheers, > Andrei > Ahhh. Nice to know. Here I was thinking it was based on some intrinsic restriction on the number of variables or something. I'm a fan of overusing redundant variables for documenting purposes... Object>>gtInspectorVariableValuePairs | indexableDisplayLimit bottom topLimit bottomLimit bindings | indexableDisplayLimit := 21. top := 1. bottom := self basicSize. topLimit := bottom min: indexableDisplayLimit. bottomLimit := (bottom - indexableDisplayLimit) max: indexableDisplayLimit. bindings := OrderedCollection new. "Return top and bottom of indexable elements" top to: topLimit do: [ :index | bindings add: (index -> (self basicAt: index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add: (index -> (self basicAt: index)) ]. "Return named variables" bindings addAll: ((self class allSlots collect: [ :slot | slot name -> (slot read: self) ]) sort asOrderedCollection). ^ bindings If this looks reasonable I'll do up a slice. Perhaps defining "top" is overkill - but it does read nice below that. btw, in general I understand that some smart optimising compilers will substitute 1 for "top" directly since its assigned a literal and not reassigned before its use. I notice from the bytecode this doesn't happen here. Is there some intrinsic difficulty in our domain stopping this to happen, or its just not been a priority. I guess while stepping through the debugger "top" a user might set a new value for "top" and reverting the substitution of "1" for "top" needs the sort of facility that Sista will provide?? On Sat, Feb 4, 2017 at 12:08 AM, Tudor Girba <tu...@tudorgirba.com> wrote: > There is very little meaning behind the number. > > The previous inspector showed the first 100 and the last 10 elements. 100 > is anyway too large for a quick inspection, so we picked another number. I > wanted 42 but that was still large, so we are now at 21. Well 21 top and bottom gives you 42, and I know life, the universe and everything depends on that number - so this seems reasonable. On Sat, Feb 4, 2017 at 12:39 AM, Aliaksei Syrel <alex.sy...@gmail.com> wrote: > They could be extracted to class vars for example TWENTY_ONE := 21. Later > if performance is still not good enough they may be changed for example to > TWENTY_ONE := 15. > (joke) > You mean something like this... https://xkcd.com/221/ cheers -ben
