Re: [sc-dev] Ref modifications

[ronald kuivila <rkuivila@xxxxxxxxxxxx>]

Hi Julian,

 I just committed the AbstractFunction part.
Seems to me that Object:ref is not really needed -we already have  
Object:asRef.
And it may create confusion.  So why don't we limit ref to  
AbstractFunction?

RJK

On Dec 20, 2008, at 9:03 AM, Julian Rohrhuber wrote:

> Hi Ron,
>
> it would probably best to use the ref method:
>
> Object {
> 	ref { ^Ref(this) }
> }
>
> AbstractFunction {
> 	^this.composeUnaryOp(\ref)
> }
>
>
> > Hi Julian,
> >
> >  OK, I will go ahead and make the changes to Ref.
> >
> >  As far as making it easier to turn a pattern or a stream into a  
> > stream of Refs, might as well enumerate the alternatives:
> >
> > 	Pref		// make it a pattern, can be applied to streams, but awkwardly
> > 	asRef		// overload asRef for Pattern and Stream classes -  
> > inconsistent with general use
> > 	ref		// make it a unary op - should it then be in AbstractFunction  
> > and apply to functions as well?
> >
> >  So, I think I vote for ref as a method of abstract function.
> >
> > RJK
> >
> >
> > On Dec 19, 2008, at 6:40 PM, Julian Rohrhuber wrote:
> >
> > > > So there are a couple of needs:
> > > >
> > > > - Protect Patterns from being embedded altogether.
> > > > - Embed the pattern but wrap its return values in a Ref so they  
> > > > don't
> > > > multichannel (rather, multi-synth) expand.
> > > >
> > > > I would vote for Ref doing the first, and some other object (not
> > > > written yet) to do the second.
> > > >
> > > > Doing both in the same object sounds confusing.
> > >
> > > yes, right.
> > >
> > > there are quite a lot of distributive messages, i.e. operations on  
> > > patterns will result in structures that apply these operations on  
> > > each of their values. I guess all we need is a unary operator that  
> > > might be called ref, which takes care of this.
> > > --
> > >
> > >
> > >
> > >
> > >
> > > .
> > >
> > > _______________________________________________
> > > sc-dev mailing list
> > >
> > > info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> > > archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> > > search: https://listarc.bham.ac.uk/lists/sc-dev/search/
> >
> >
> > _______________________________________________
> > sc-dev mailing list
> >
> > info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> > archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> > search: https://listarc.bham.ac.uk/lists/sc-dev/search/
>
>
> --
>
>
>
>
>
> .
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> search: https://listarc.bham.ac.uk/lists/sc-dev/search/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/