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?
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

Back to the top