[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Re: [sc-users] Synth.play revisited

On Wednesday, July 24, 2002, at 07:11 PM, Julian Rohrhuber wrote:

i'd like to re-iterate the importance of that statement. perhaps we (anyone who's read design patterns or some equivalent) could outline some general ideas of class building, giving full credit to the authors of the book of course. perhaps this would be helpful (not only with SC code, but also with the underlying obj-c and c++ code) to others so that class conflicts such as
these can be avoided.

The topic is an interesting one. Design is dependant on what someone
wants to do with a system and what concepts have to be balanced out.
Normally I would never have used Instr as a name, this was just to
start a conversation on this kind of problems and I hope that this was not
Often other people's code is hard to read, especially when it is
trying to make something work. Class systems tend to slowly approach
a point where they get a more descriptive tendency - but again this is
connected to what is needed and this often comes out while working on it.
In order to investigate how a class should one has to talk about what it
should do.  Of course many mistakes can be avoided by knowing the system
that already exists (especially in sc) as well as simple design patterns
(like the ones in Best Practice Patterns by Kent Beck).

i think the former is what really applies here.. most patterns out there won't apply to SC (lang anyway) directly. good OO coding is whats needed it seems

with play, why not do something like how protoEvent worked. can't you assume some default values there?

I probably should have played with SC classes some, I really havent done any code with them at all...