In the Java Eclipse IDE, there is a refactoring called Delegate: generate Methods to forward the call to a member variable. This is good because you don't have to write so much, this is bad because there is so much code, doing nothing :)

How about making this into the D language:

class A{
    int getPrice(){ return 0; }
    void print( int a ){}
    void print( double a ){}
}

class B{
    private   A a;

    alias a.getPrice getPrice;
    /** Same like writing
    int getPrice(){ return a.getPrice(); }
    */

    alias a.print print;
    /** Same like writing
    void print( int a ){ a.print( a ); }
    void print( double a ){ a.print( a ); }
    */
}

void main(){
    B b = new B;
    b.print( 1 );
}

The advantage is, changing the signature in A, automatically is visible for users of B. Less code, more consistency.

Frank Benoit wrote:
> In the Java Eclipse IDE, there is a refactoring called Delegate:
> generate Methods to forward the call to a member variable. This is good
> because you don't have to write so much, this is bad because there is so
> much code, doing nothing :)
> 
> How about making this into the D language:
> 
> class A{
>     int getPrice(){ return 0; }
>     void print( int a ){}
>     void print( double a ){}
> }
> 
> class B{
>     private   A a;
> 
>     alias a.getPrice getPrice;
>     /** Same like writing
>     int getPrice(){ return a.getPrice(); }
>     */
> 
>     alias a.print print;
>     /** Same like writing
>     void print( int a ){ a.print( a ); }
>     void print( double a ){ a.print( a ); }
>     */
> }
> 
> void main(){
>     B b = new B;
>     b.print( 1 );
> }
> 
> The advantage is, changing the signature in A, automatically is visible
> for users of B. Less code, more consistency.
> 

I'll second this one.  Its a natural evolution of the current use of alias to do method inheritance when overloading.

-- Chris Nicholson-Sauls

Why wouldn't you make B inherit from A ?  Or make those methods a mixin ?


Frank Benoit wrote:
> In the Java Eclipse IDE, there is a refactoring called Delegate:
> generate Methods to forward the call to a member variable. This is good
> because you don't have to write so much, this is bad because there is so
> much code, doing nothing :)
> 
> How about making this into the D language:
> 
> class A{
>     int getPrice(){ return 0; }
>     void print( int a ){}
>     void print( double a ){}
> }
> 
> class B{
>     private   A a;
> 
>     alias a.getPrice getPrice;
>     /** Same like writing
>     int getPrice(){ return a.getPrice(); }
>     */
> 
>     alias a.print print;
>     /** Same like writing
>     void print( int a ){ a.print( a ); }
>     void print( double a ){ a.print( a ); }
>     */
> }
> 
> void main(){
>     B b = new B;
>     b.print( 1 );
> }
> 
> The advantage is, changing the signature in A, automatically is visible
> for users of B. Less code, more consistency.
> 

Carlos wrote:
> Why wouldn't you make B inherit from A ?
> 

Adapters.  For example, let's say you've got these two classes:

class Switch
{
    void toggle() { ... }
}

class PushButton
{
    void toggle() { ... }
}

Now, let's say you have a PushButton, but you need to pass something a Switch.  They're semantically the same, they've even got the same members, but you just can't do it.  You can't subclass them BOTH since D doesn't allow multiple inheritance, and whoever wrote Switch didn't think to use an interface that could be implemented either.

The solution here is to write an object that adapts the PushButton into a Switch.

class PushButtonSwitch : Switch
{
    PushButton realButton;
    void toggle() { realButton.toggle(); }
}

That's what he's referring to.  At least, I think it is.

> Or make those methods a mixin ?

The problem with that is that you've still got to write the methods in the first place.  If you need to adapt several different objects, but only once a piece, then the mixin is a waste of time.  His suggestion is to automate writing the trivial (but repetitive an annoying) code to redirect the calls.

Now, MY solution would be to allow objects to override attribute lookup, but then this ain't Python :P

	-- Daniel

> 
> Frank Benoit wrote:
>> In the Java Eclipse IDE, there is a refactoring called Delegate: generate Methods to forward the call to a member variable. This is good because you don't have to write so much, this is bad because there is so much code, doing nothing :)
>>
>> How about making this into the D language:
>>
>> class A{
>>     int getPrice(){ return 0; }
>>     void print( int a ){}
>>     void print( double a ){}
>> }
>>
>> class B{
>>     private   A a;
>>
>>     alias a.getPrice getPrice;
>>     /** Same like writing
>>     int getPrice(){ return a.getPrice(); }
>>     */
>>
>>     alias a.print print;
>>     /** Same like writing
>>     void print( int a ){ a.print( a ); }
>>     void print( double a ){ a.print( a ); }
>>     */
>> }
>>
>> void main(){
>>     B b = new B;
>>     b.print( 1 );
>> }
>>
>> The advantage is, changing the signature in A, automatically is visible for users of B. Less code, more consistency.
>>

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/

I see thanks for the clarification.

Whats attribute lookup about ?

Daniel Keep wrote:
> 
> Carlos wrote:
>> Why wouldn't you make B inherit from A ?
>>
> 
> Adapters.  For example, let's say you've got these two classes:
> 
> class Switch
> {
>     void toggle() { ... }
> }
> 
> class PushButton
> {
>     void toggle() { ... }
> }
> 
> Now, let's say you have a PushButton, but you need to pass something a
> Switch.  They're semantically the same, they've even got the same
> members, but you just can't do it.  You can't subclass them BOTH since D
> doesn't allow multiple inheritance, and whoever wrote Switch didn't
> think to use an interface that could be implemented either.
> 
> The solution here is to write an object that adapts the PushButton into
> a Switch.
> 
> class PushButtonSwitch : Switch
> {
>     PushButton realButton;
>     void toggle() { realButton.toggle(); }
> }
> 
> That's what he's referring to.  At least, I think it is.
> 
>> Or make those methods a mixin ?
> 
> The problem with that is that you've still got to write the methods in
> the first place.  If you need to adapt several different objects, but
> only once a piece, then the mixin is a waste of time.  His suggestion is
> to automate writing the trivial (but repetitive an annoying) code to
> redirect the calls.
> 
> Now, MY solution would be to allow objects to override attribute lookup,
> but then this ain't Python :P
> 
> 	-- Daniel
> 
>> Frank Benoit wrote:
>>> In the Java Eclipse IDE, there is a refactoring called Delegate:
>>> generate Methods to forward the call to a member variable. This is good
>>> because you don't have to write so much, this is bad because there is so
>>> much code, doing nothing :)
>>>
>>> How about making this into the D language:
>>>
>>> class A{
>>>     int getPrice(){ return 0; }
>>>     void print( int a ){}
>>>     void print( double a ){}
>>> }
>>>
>>> class B{
>>>     private   A a;
>>>
>>>     alias a.getPrice getPrice;
>>>     /** Same like writing
>>>     int getPrice(){ return a.getPrice(); }
>>>     */
>>>
>>>     alias a.print print;
>>>     /** Same like writing
>>>     void print( int a ){ a.print( a ); }
>>>     void print( double a ){ a.print( a ); }
>>>     */
>>> }
>>>
>>> void main(){
>>>     B b = new B;
>>>     b.print( 1 );
>>> }
>>>
>>> The advantage is, changing the signature in A, automatically is visible
>>> for users of B. Less code, more consistency.
>>>
> 

Carlos wrote:
> I see thanks for the clarification.
> 
> Whats attribute lookup about ?

Basically, in Python you can override the lookup of an object's members such that

	Foo.bar

Becomes

	Foo.__getattr__("bar")

This allows you to make objects that dynamically grow new attributes. It's frankly amazing how useful this is.  I've used it several times, and it can really help to simplify code.

Of course, it can also be used for unspeakable evil, but that seems to be the way with most power features :)

	-- Daniel

> 
> Daniel Keep wrote:
>>
>> Carlos wrote:
>>> Why wouldn't you make B inherit from A ?
>>>
>>
>> Adapters.  For example, let's say you've got these two classes:
>>
>> class Switch
>> {
>>     void toggle() { ... }
>> }
>>
>> class PushButton
>> {
>>     void toggle() { ... }
>> }
>>
>> Now, let's say you have a PushButton, but you need to pass something a Switch.  They're semantically the same, they've even got the same members, but you just can't do it.  You can't subclass them BOTH since D doesn't allow multiple inheritance, and whoever wrote Switch didn't think to use an interface that could be implemented either.
>>
>> The solution here is to write an object that adapts the PushButton into a Switch.
>>
>> class PushButtonSwitch : Switch
>> {
>>     PushButton realButton;
>>     void toggle() { realButton.toggle(); }
>> }
>>
>> That's what he's referring to.  At least, I think it is.
>>
>>> Or make those methods a mixin ?
>>
>> The problem with that is that you've still got to write the methods in the first place.  If you need to adapt several different objects, but only once a piece, then the mixin is a waste of time.  His suggestion is to automate writing the trivial (but repetitive an annoying) code to redirect the calls.
>>
>> Now, MY solution would be to allow objects to override attribute lookup, but then this ain't Python :P
>>
>>     -- Daniel
>>
>>> Frank Benoit wrote:
>>>> In the Java Eclipse IDE, there is a refactoring called Delegate:
>>>> generate Methods to forward the call to a member variable. This is good
>>>> because you don't have to write so much, this is bad because there
>>>> is so
>>>> much code, doing nothing :)
>>>>
>>>> How about making this into the D language:
>>>>
>>>> class A{
>>>>     int getPrice(){ return 0; }
>>>>     void print( int a ){}
>>>>     void print( double a ){}
>>>> }
>>>>
>>>> class B{
>>>>     private   A a;
>>>>
>>>>     alias a.getPrice getPrice;
>>>>     /** Same like writing
>>>>     int getPrice(){ return a.getPrice(); }
>>>>     */
>>>>
>>>>     alias a.print print;
>>>>     /** Same like writing
>>>>     void print( int a ){ a.print( a ); }
>>>>     void print( double a ){ a.print( a ); }
>>>>     */
>>>> }
>>>>
>>>> void main(){
>>>>     B b = new B;
>>>>     b.print( 1 );
>>>> }
>>>>
>>>> The advantage is, changing the signature in A, automatically is visible for users of B. Less code, more consistency.
>>>>
>>

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/