dsimcha Wrote:

> This is why I don't want to see @property fully implemented.  Ever.  I love this method chaining stuff and you can pry it out of my cold, dead hands.  There was a discussion about this a long time ago when I was writing the first version of Plot2kill that gave me the impression that @property was to be used for disambiguation only.  (See http://www.digitalmars.com/d/archives/digitalmars/D/Overloading_property_vs._non-property_113421.html .)
> 
> The problem with the with statement idea is that you still need to declare the variable.  I often throw up quick anonymous plots with anonymous Figure objects, like:
> 
> Histogram(someDataSet).toFigure
>      .title("A Title")
>      .xLabel("Stuff")
>      .showAsMain();

What do you think about C# object initializers? http://msdn.microsoft.com/en-us/library/bb384062.aspx

On 3/10/2011 10:03 AM, Kagamin wrote:
> dsimcha Wrote:
>
>> This is why I don't want to see @property fully implemented.  Ever.  I
>> love this method chaining stuff and you can pry it out of my cold, dead
>> hands.  There was a discussion about this a long time ago when I was
>> writing the first version of Plot2kill that gave me the impression that
>> @property was to be used for disambiguation only.  (See
>> http://www.digitalmars.com/d/archives/digitalmars/D/Overloading_property_vs._non-property_113421.html
>> .)
>>
>> The problem with the with statement idea is that you still need to
>> declare the variable.  I often throw up quick anonymous plots with
>> anonymous Figure objects, like:
>>
>> Histogram(someDataSet).toFigure
>>       .title("A Title")
>>       .xLabel("Stuff")
>>       .showAsMain();
>
> What do you think about C# object initializers?
> http://msdn.microsoft.com/en-us/library/bb384062.aspx

They work about as well as a with() statement and not as well as method chaining.  The problem is that the toFigure call returns a different type.  The idiomatic way to use Plot2kill is to create a Plot, set all the Plot properties you need, call toFigure, then set all the Figure properties you need.  (Plot and Figure are distinct because you can have more than one Plot on a Figure, though you often don't.)  Example:

Histogram(someDataSet, 10)
    .barColor(getColor(255, 0, 0))
    .histType(HistType.Probability)
    .toFigure
    .title("A Histogram")
    .showAsMain();

dsimcha Wrote:

> They work about as well as a with() statement and not as well as method chaining.  The problem is that the toFigure call returns a different type.  The idiomatic way to use Plot2kill is to create a Plot, set all the Plot properties you need, call toFigure, then set all the Figure properties you need.  (Plot and Figure are distinct because you can have more than one Plot on a Figure, though you often don't.)  Example:
> 
> Histogram(someDataSet, 10)
>      .barColor(getColor(255, 0, 0))
>      .histType(HistType.Probability)
>      .toFigure
>      .title("A Histogram")
>      .showAsMain();

new Figure
{
   title="A Histogram",
   new Histogram
   {
      barColor=getColor(255, 0, 0),
      histType=HistType.Probability
   }
}

not sure, what showAsMain means.

forgot about dataset

> Histogram(someDataSet, 10)
>      .barColor(getColor(255, 0, 0))
>      .histType(HistType.Probability)
>      .toFigure
>      .title("A Histogram")
>      .showAsMain();

new Figure
{
   title="A Histogram",
   new Histogram(someDataSet, 10)
   {
      barColor=getColor(255, 0, 0),
      histType=HistType.Probability
   }
}

dsimcha Wrote:

> The problem with the with statement idea is that you still need to declare the variable.  I often throw up quick anonymous plots with anonymous Figure objects, like:
> 
> Histogram(someDataSet).toFigure
>      .title("A Title")
>      .xLabel("Stuff")
>      .showAsMain();

It's also easier to debug code if you store objects in variables. What if histogram is created with a bug, how would you diagnose it? If you have the histogram stored in a variable, you can put a breakpoint after the assignment and inspect the histogram, but your example doesn't provide a variable to inspect.

On 3/11/11 8:49 AM, Kagamin wrote:
> It's also easier to debug code if you store objects in variables. What if histogram is created with a bug, how would you diagnose it? If you have the histogram stored in a variable, you can put a breakpoint after the assignment and inspect the histogram, but your example doesn't provide a variable to inspect.

Just put a break point at the beginning of the line and step through it?

David

On 3/11/2011 2:49 AM, Kagamin wrote:
> dsimcha Wrote:
>
>> The problem with the with statement idea is that you still need to
>> declare the variable.  I often throw up quick anonymous plots with
>> anonymous Figure objects, like:
>>
>> Histogram(someDataSet).toFigure
>>       .title("A Title")
>>       .xLabel("Stuff")
>>       .showAsMain();
>
> It's also easier to debug code if you store objects in variables. What if histogram is created with a bug, how would you diagnose it? If you have the histogram stored in a variable, you can put a breakpoint after the assignment and inspect the histogram, but your example doesn't provide a variable to inspect.

Well, then give it a name if you ever end up needing to.  In general I hate this as an argument against terse but readable code because you can always make things into named variables very easily if you ever need to set a breakpoint there.  Usually I use as few named variables as I can without hurting readability when I program, both to save typing and because I find it hard to think of good names for intermediate variables, so I end up naming them something horrible.

David Nadlinger Wrote:

> On 3/11/11 8:49 AM, Kagamin wrote:
> > It's also easier to debug code if you store objects in variables. What if histogram is created with a bug, how would you diagnose it? If you have the histogram stored in a variable, you can put a breakpoint after the assignment and inspect the histogram, but your example doesn't provide a variable to inspect.
> 
> Just put a break point at the beginning of the line and step through it?

Those are library methods. You probably won't have sources for them, but you can still access its properties or inspect private members if you have appropriate symbols for them. It also can be quite tedious to step through those chained methods, because the chain can be long.
May be m$ debugger sucks, but it's nontrivial to step through methods called in single statement: it tends to step through the whole statement, though you can step-in and step-out.

> > Just put a break point at the beginning of the line and step through it?
> May be m$ debugger sucks, but it's nontrivial to step through methods called in single statement: it tends to step through the whole statement, though you can step-in and step-out.

You will also step into functions called for arguments like getColor() in the example.

== Quote from Kagamin (spam@here.lot)'s article
> > > Just put a break point at the beginning of the line and step through it?
> > May be m$ debugger sucks, but it's nontrivial to step through methods called
in single statement: it tends to step through the whole statement, though you can step-in and step-out.
> You will also step into functions called for arguments like getColor() in the
example.

Ok, I'll admit I don't know much about this stuff.  I debug mostly with asserts and print statements.  I very seldom use a debugger.