Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] any objections to changing the "toString" of the CollectionType?

  that is odd - i wonder why we are seeing different behavior.
 
  maybe we should just split the difference and make that some kind of preference setting. i don't mind having to click on the actual variable in the display view in order to see what's inside and would prefer not to see what's inside the collection unless i specifically ask to.

  i can work on adding a preference to toggle between the two.
 
On Wed, Jul 2, 2008 at 9:07 AM, Johan Compagner <jcompagner@xxxxxxxxx> wrote:
weird in my Eclipse debugger it does show:

globals    IScriptVariable[]    [allnames, length, globals, currentcontroller, i18n, utils, security, application, history, databaseManager, ServoyException, plugins]    IScriptVariable[]    838   

And i dont have default formatters (in the preferences) and toggling between logical structures doesnt matter..

And i really like that behavior way more then that what you show in your screenshot. Thats doesnt display any information that is relevant to me.

johan



On Wed, Jul 2, 2008 at 2:56 PM, Jae Gangemi <jgangemi@xxxxxxxxx> wrote:

  wait - i'm still not a fan of this solution. take a look at the attached screen shot of a java session.

  the collapsed List and char array don't show any 'preview' of what is inside in the table view, but the details view shows the actual contents of of the char array (although you do have to click on the entry in the table for the details pane to be popiulated). that's the same behavior i'd like to see happen here. (i'm not sure why collections in your view display something else, maybe there some option to turn that on?).

  right now, the details pane and the entry in the variables table are the same b/c the underlying code calls the same method to get that value. my next step was going to be to refactor that to add a separate call to get the detail pane text.


On Wed, Jul 2, 2008 at 8:34 AM, Johan Compagner <jcompagner@xxxxxxxxx> wrote:
thats why i did take getRawValue() so that the Value itself would output the type (and for what i am testing it was "Array" for _javascript_ and so on)

But i could just create _javascript_ subclasses in the _javascript_TypeFactory to override the public String formatValue(IScriptValue value)  method now
so we could move all the formatting the script implementations


johan


On Wed, Jul 2, 2008 at 2:29 PM, Alex Panchenko <alex@xxxxxxxxx> wrote:
The word "Array" should depend on the type of collection - the code is now in CollectionScriptType and there are some descendants.

Another option to customize is braces around array elements
{1,2,3} vs [1,2,3] vs (1,2,3)
and that is languages specific, AFAIK

Alex

Johan Compagner wrote:
yeah for ruby the [size] is a bit strange looking if you have first [...] in front of it.
Maybe sb.append(value.getRawValue()); is not a good idea to have default?
I can live with just
sb.append("Array");
?
johan

On Wed, Jul 2, 2008 at 2:19 PM, Alex Panchenko <alex@xxxxxxxxx <mailto:alex@xxxxxxxxx>> wrote:

   I like the idea to display some of the array elements, but the
   basic implementation should have some options how to display values.
   e.g. now in ruby array is displayed as

   [...][3]{1,2,3} (id = 23638800)

   Strange, isn't it?

   So my intention is that basic implementation should be generally
   usable and language specifics should be added via inheritance or
   parameters passed in the constructor.

   Alex

   Jae Gangemi wrote:


        that 'number[8]' is supposed to work like the java debugger
       where if you have an aray you see something like char[5] which
       tells you that it's a character array and it has a size of 5.

        so in this case, you have an array of numbers w/ a size of 8.

        looking at the type of the first element for a script array
       may not make sense b/c they can be heterogenous.

        i'd like the behavior to remain consistent w/ how the java
       debugger works (if possible), where the details pane shows the
       'expanded' values, while the collapsed array (and/or hash)
       continues to show at 'somthing[size]'. i was going to work on
       a way to override what gets displayed in the details pane if
       you don't have a detail formatter setup next or the debugger
       engine doesn't support evaluations.

        the implemenation below would end up in a method like
       'formatDetailView' or something along those lines.

       On Wed, Jul 2, 2008 at 6:10 AM, Johan Compagner
       <jcompagner@xxxxxxxxx <mailto:jcompagner@xxxxxxxxx>
       <mailto:jcompagner@xxxxxxxxx <mailto:jcompagner@xxxxxxxxx>>>

       wrote:

          Now we get something like this in the debugger:

          "number[8]"

          What does that say? Nobody can see whats really in it without
          really expanding it and so on
          The Rhino debugger (the old one) did this:

          "Array(10.0,200.0,30.0,40.0,5006.0,700.0,200.0,"johan")"

          Of course not the complete array values limit it (currently 100
          values)

          This is the code:

          public String formatValue(IScriptValue value) {
                  StringBuffer sb = new StringBuffer();
                  sb.append(value.getRawValue()); // == Array
                  sb.append("("); // == Array

                  try {
                      IVariable[] variables2 = value.getVariables();
                      if (variables2.length > 0) {
                          int length = variables2.length;
                          length = length > 100 ? 100 : length;
                          for (int i = 0; i < variables2.length; i++) {
                                      sb.append(variables2[i].getValue().getValueString());
                              sb.append(",");
                          }
                          sb.setLength(sb.length() - 1);
                      }
                  } catch (DebugException ex) {
                      ex.printStackTrace();
                  }
                  sb.append(")"); // == Array

                  addInstanceId(value, sb);

                  return sb.toString();
              }

          Should i commit this? Or are you guys liking the current
       behavior
          better?

          johan


          _______________________________________________
          dltk-dev mailing list
          dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
       <mailto:dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>>


          https://dev.eclipse.org/mailman/listinfo/dltk-dev




       --        -jae
       ------------------------------------------------------------------------



       _______________________________________________
       dltk-dev mailing list
       dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
       https://dev.eclipse.org/mailman/listinfo/dltk-dev
       
   _______________________________________________
   dltk-dev mailing list
   dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
   https://dev.eclipse.org/mailman/listinfo/dltk-dev


------------------------------------------------------------------------

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
 
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev


_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev




--
-jae
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev



_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev




--
-jae

Back to the top