> On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman <btc@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 <chisvasileandrei@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��<tudor@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.syrel@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