[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sc-devel] server naming conventions cleanup?
Ross,
I'd vote in favour of your two changes.
Dan
2008/1/17, Ross Bencina <rossb-lists@xxxxxxxxxxxxxx>:
> >I don't think that a cosmetic change to the source code is a valid
> > reason to break plug ins - ever. I think we should live with it the
> > way it is.
>
> That's kind of killed the conversation before we finished. For a start it's
> not clear what "break plugins" means -- are we talking about breaking binary
> compatibility (changing enum values or structure layout) or changing source
> compatibility (just changing names). And which plugins are we talking about?
> We can always fix the ones which are part of the distro within any
> name-change patch.
>
> Private plugins could depend on any and all of the server source code in one
> way or another so I don't see a clear way to follow this guidance and move
> forward in improving the quality and redability of the server source code...
>
> The main requested changes from my original post are below, I'm still
> pushing for (1) because it makes it hard to read and write the server code
> and (2) because it makes it unnecessarily hard to understand. If backwards
> compatibility with plugins is the only issue then I'll prepare a patch which
> includes typedefs or defines as necessary to the old names (not so easy with
> file name changes)..
>
> 1. - Inconsistent use of SC_ prefix: sometimes it's there, sometimes it
> isn't.
> This applies to both source files and headers.. often one or the other uses
> SC_ but not both. I can provide a full table of these if necessary. At a
> minimum, in terms of types, I'd recommend removing SC from
> SC_BufReadCommand, SC_SequencedCommand and SC_LibCmd. All other types with
> SC_ are generic system object (like SC_Lock) which could easily collide if
> we removed SC. The alternative is to be add SC_ everywhere or remove it
> everywhere
>
> 2. - Now for the big one: I'd like to see Graph renamed to Synth, and
> GraphDef
> renamed to SynthDef. There's 400 occurences of "Graph" in the source code,
> but the IOUgens seem to be the only plugins which reference the name.
>
> Ross.
>
>
>
> >
> > --- james mccartney @ iphone
> >
> > On Jan 12, 2008, at 2:20 AM, "Dan Stowell" <danstowell@xxxxxxxxx> wrote:
> >
> >> Well FWIW I don't agree with Ross, I think that keeping both for 3.2
> >> and then dumping the old one for 3.3 would be standard deprecation
> >> practice. But I'm not strongly motivated, happy to leave them named as
> >> they are.
> >>
> >> Dan
> >>
> >>
> >> 2008/1/12, Click Nilson <clicksonnil@xxxxxxxxx>:
> >>> Changing this seems like it would impact on a lot of plugins; would
> >>> seem too much to force everyone to recompile everything to be
> >>> compatible with 3.2. Can we please keep the old names even if they're
> >>> not the most elegant? (though actually, we might live perfectly well
> >>> with calc_BufRate, as Ross also notes, and this is the only
> >>> controversial one). Or at least allow both to persist; unlike Ross, I
> >>> don't recommend a harsh name swap at this notice.
> >>>
> >>> just my opinion,
> >>> N
> >>>
> >>> On 10 Jan 2008, at 14:56, ronald kuivila wrote:
> >>>
> >>>> Hi guys,
> >>>>
> >>>> This may be gelding the lily, but...
> >>>> How about calc_SampleBlockRate and, for consistency,
> >>>> calc_SampleRate?
> >>>>
> >>>>
> >>>> RJK
> >>>>
> >>>> On Jan 10, 2008, at 6:38 AM, Ross Bencina wrote:
> >>>>
> >>>>> Hi Dan
> >>>>>
> >>>>> Thanks for the feedback... re the rates stuff:
> >>>>>
> >>>>>> I'd also like to mention one which came up re my chapter. In the
> >>>>>> plugin API the constants for the different rates are
> >>>>>> calc_ScalarRate
> >>>>>> (scalar-rate), calc_BufRate (control-rate), calc_FullRate
> >>>>>> (audio-rate), calc_DemandRate (demand-rate). "calc_BufRate" to me
> >>>>>> is a
> >>>>>> bit opaque/confusing and it would perhaps be more helpful to
> >>>>>> change
> >>>>>> over to "calc_ControlRate"? (Both constants would be preserved
> >>>>>> for a
> >>>>>> while, with calc_BufRate being deprecated, since it's in the API.)
> >>>>>> Grateful for thoughts on that.
> >>>>>
> >>>>> Seems like ControlRate would make more sense for people who are in
> >>>>> the know,
> >>>>> but "BufRate" is actually more accurate to the semantics of the
> >>>>> operation
> >>>>> imho..
> >>>>>
> >>>>> I don't like the idea of keeping both.. I say break plugins and
> >>>>> change the
> >>>>> name. If it has the same value it will only break things on
> >>>>> recompile and
> >>>>> developers will soon sort that out.
> >>>>>
> >>>>> R.
> >>>>> _______________________________________________
> >>>>> Sc-devel mailing list
> >>>>> Sc-devel@xxxxxxxxxxxxxxx
> >>>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Sc-devel mailing list
> >>>> Sc-devel@xxxxxxxxxxxxxxx
> >>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> >>>
> >>> _______________________________________________
> >>> Sc-devel mailing list
> >>> Sc-devel@xxxxxxxxxxxxxxx
> >>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> >>>
> >>
> >>
> >> --
> >> http://www.mcld.co.uk
> >> _______________________________________________
> >> Sc-devel mailing list
> >> Sc-devel@xxxxxxxxxxxxxxx
> >> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> > _______________________________________________
> > Sc-devel mailing list
> > Sc-devel@xxxxxxxxxxxxxxx
> > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> >
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>
--
http://www.mcld.co.uk