Easy Bulk Delegation in Scala?

On Sunday March 29 2009, Randall R Schulz wrote:
> Hi,
>
> Say I have a factory trait:
>
> trait FormulaFactory {
> // Many makeThisOrThat methods
> }
>
>
> And a couple of implementing classes:

Of course, these were meant to include "extends" clauses:

> class BasicFormulaFactory
extends FormulaFactory
> {
> // Implementation of all FormulaFactory methods
> }
>
> class MemoizedFormulaFactory
extends FormulaFactory
> {
> // Implementation of all FormulaFactory methods
> }
>
>
> And an object that captures a system-wide default factory:
>
> object DefaultFormulaFactory
> extends FormulaFactory
> {
> val builder = new BasicFormulaFactory
>
> // Many methods delegating FormulaFactory methods via builder
> }
>
>
>
> Is there a way to write the DefaultFormulaFactory object that does
> not require a delegating method for each of the methods in the trait
> it extends?

RRS

Since builder is a val, it seems to me you could just do

object DefaultFormulaFactory extends BasicFormulaFactory

without losing any flexibility.

-----Original Message-----
From: Randall R Schulz [mailto:rschulz@sonic.net]
Sent: Sunday, March 29, 2009 3:26 PM
To: scala-user@listes.epfl.ch
Subject: [scala-user] Easy Bulk Delegation in Scala?

Hi,

Say I have a factory trait:

trait FormulaFactory {
// Many makeThisOrThat methods
}

And a couple of implementing classes:

class BasicFormulaFactory {
// Implementation of all FormulaFactory methods }

class MemoizedFormulaFactory {
// Implementation of all FormulaFactory methods }

And an object that captures a system-wide default factory:

object DefaultFormulaFactory
extends FormulaFactory
{
val builder = new BasicFormulaFactory

// Many methods delegating FormulaFactory methods via builder }

Is there a way to write the DefaultFormulaFactory object that does not
require a delegating method for each of the methods in the trait it
extends?

Randall Schulz

PLEASE READ: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please delete it and all copies from your system, destroy any hard copies and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Nomura Holding America Inc., Nomura Securities International, Inc, and their respective subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state the views of such entity. Unless otherwise stated, any pricing information in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.

On Monday March 30 2009, Frohnhofer, James wrote:
> Since builder is a val, it seems to me you could just do
>
> object DefaultFormulaFactory extends BasicFormulaFactory
>
> without losing any flexibility.

I didn't mention that the point of having the default factory is to be
able to choose which actual factory you're going to use at run-time.

> ...
>
> PLEASE READ: This message is for the named person's use only.

PLEASE DON'T include silly things like this in message to public lists.

Randall Schulz

Your name is not "scala-user" so the message was not intended for you.

On Mon, Mar 30, 2009 at 6:59 AM, Randall R Schulz <rschulz@sonic.net> wrote:

>
> PLEASE READ: This message is for the named person's use only.

PLEASE DON'T include silly things like this in message to public lists.


Randall Schulz

I suppose my point was that the object/val combination wasn't going to
provide the runtime flexibility you wanted, at least not in that form.
I'm a relative newbie her, so I probably shouldn't be so flip, as I'm
often wrong.

It seems to me utimately you're looking for a global variable with
mutable state.

(Sorry about the boilerplate at the bottom - can't turn it off; can't
use a personal account at work.)

-----Original Message-----
From: Randall R Schulz [mailto:rschulz@sonic.net]
Sent: Monday, March 30, 2009 9:59 AM
To: scala-user@listes.epfl.ch
Subject: Re: [scala-user] Easy Bulk Delegation in Scala?

On Monday March 30 2009, Frohnhofer, James wrote:
> Since builder is a val, it seems to me you could just do
>
> object DefaultFormulaFactory extends BasicFormulaFactory
>
> without losing any flexibility.

I didn't mention that the point of having the default factory is to be
able to choose which actual factory you're going to use at run-time.

> ...
>
> PLEASE READ: This message is for the named person's use only.

PLEASE DON'T include silly things like this in message to public lists.

Randall Schulz

PLEASE READ: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please delete it and all copies from your system, destroy any hard copies and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Nomura Holding America Inc., Nomura Securities International, Inc, and their respective subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state the views of such entity. Unless otherwise stated, any pricing information in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.

On Monday March 30 2009, James Iry wrote:
> Your name is not "scala-user" so the message was not intended for
> you.

Odd. I answer to "scala-user."

As in: "Hey you! Scala-user! Don't use nulls! Arrays, either!"
To which I respond: "Mind your own business."

RRS

I wonder what you have to write to ensure your readers cannot be prosecuted for reading.   "Please disregard the following boilerplate rubbish"?

2009/3/30 Frohnhofer, James <james.frohnhofer@nomura.com>

I suppose my point was that the object/val combination wasn't going to
provide the runtime flexibility you wanted, at least not in that form.
I'm a relative newbie her, so I probably shouldn't be so flip, as I'm
often wrong.

It seems to me utimately you're looking for a global variable with
mutable state.

(Sorry about the boilerplate at the bottom - can't turn it off; can't
use a personal account at work.)

-----Original Message-----
From: Randall R Schulz [mailto:rschulz@sonic.net]
Sent: Monday, March 30, 2009 9:59 AM
To: scala-user@listes.epfl.ch
Subject: Re: [scala-user] Easy Bulk Delegation in Scala?

On Monday March 30 2009, Frohnhofer, James wrote:
> Since builder is a val, it seems to me you could just do
>
>    object DefaultFormulaFactory extends BasicFormulaFactory
>
> without losing any flexibility.

I didn't mention that the point of having the default factory is to be
able to choose which actual factory you're going to use at run-time.


> ...
>
> PLEASE READ: This message is for the named person's use only.

PLEASE DON'T include silly things like this in message to public lists.


Randall Schulz


PLEASE READ: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please delete it and all copies from your system, destroy any hard copies and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Nomura Holding America Inc., Nomura Securities International, Inc, and their respective subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state the views of such entity. Unless otherwise stated, any pricing information in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.

I had some uses for delegating not so long ago (before I was using Scala).One was to make a JDBC "driver" that delegated over RMI, so it couldn't extends the class it delegated to.The other time I think was more similar to your case. I wanted a custom swing combo box to support any look and feel, but the only way I got it to use a different component for the drop down (popup) was to extend the UI class. I extended a certain LAF UI, but with delegating (a lot of methods) it could adapt to whatever LAF was installed. But you have to admit, delegating in Scala is much more concise!

On Mon, Mar 30, 2009 at 10:52 AM, Randall R Schulz <rschulz@sonic.net> wrote:

On Monday March 30 2009, James Iry wrote:
> Your name is not "scala-user" so the message was not intended for
> you.

Odd. I answer to "scala-user."

As in: "Hey you! Scala-user! Don't use nulls! Arrays, either!"
To which I respond: "Mind your own business."


RRS