Re: [sc-dev] Ref modifications

[Julian Rohrhuber <rohrhuber@xxxxxxxxxxxxxx>]

> 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?

ok, let's wait until we get a case in which uniformity is required.



> 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/


--





.

_______________________________________________
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/