Re: [sc-dev] environments as prototypes

[James Harkins <jamshark70@xxxxxxxxx>]

On Aug 1, 2006, at 2:54 PM, Julian Rohrhuber wrote:

One solution was to use a different method ("call")

so

e = (postMe: { "I am just an environment".postln });

e.postMe;

would become

e.call(\postMe)

* pro:

faster

easier to understand

* con:

setter not usable (e.g e.x = 7 becomes e.call(\x_, 7) or e[\x] = 7)

does not mix well with methiod calls -> polymorphism lost.

Would this be for all pseudo-method calls or just those that override true methods defined in the class tree?

My solution in AdhocClass is to define certain methods in AdhocClass to pass the message on to the environment.

next { arg ... args;

var result;

env.use({ result = ~next.valueArray([this] ++ args); });

^result

}

... and so on for value, reset, update (which is very important for dependency support), asStream, and...

use { arg func;

var result;

env.use({ result = func.value; });

^result

}

free { arg ... args;

env.use({ ~free.valueArray([this] ++ args) });

env = nil;

}

The drawbacks are clutter in the class def, and it does not dynamically adapt to new methods that might be defined in Environment or superclasses (admitting that it may not be technically possible to do that kind of dynamic adaptation).

Or, maybe a better question is -- do we know what the requirements are? That is, desired behavior for a given input? The requirements are clear for a method selector not defined in the class tree. What do we want it to do otherwise?

hjh

: H. James Harkins

: jamshark70@xxxxxxxxxxxxxxxxx

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman