[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

regularly I realize how useful they are, even if some of them might
seem over obvious and some seem never needed. A year ago I've started a drag
and drop system for sc3d and reading about multiple dispatch was very useful.

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

what do you mean?