| Eric Lyon, for some reason calling himself Red Hat Linux User, wrote:
> I'm glad to hear that there is considerable enthusiasm in response to
> Paul Winkler's recent excellent Perl proposals.
Me too. Actually I'm a little worried by it-- people want things I
hadn't thought of! Too much work to do!
> Let me be the one crank to suggest that OOP is not necessarily the way
> to go, or perhaps is suitable for only some of the many possibilities
> to which Paul alluded.
I wonder if maybe a mixed approach is a reasonable idea... but the
impression I get is that once you hide data inside an object, things go
haywire if you try to fiddle with it without using the object's methods.
Can anyone tell me if this a misconception?
> OOP has several well documented benefits. However it has a few
> downsides -
>
> 1) You have to do more typing to make something happen than with
> procedural code.
Bummer. In fact, BIG bummer.
> 2) There is more structural overhead to consider when designing object
> frameworks, which both distracts from the compositional task at hand
> and can force the programmer/composer to make quick decisions about
> structure which may later irritate him/her and/or other users who try
> to build on or cannibalize the code.
That's a concern also. I think I'd rather implement something that left
you with maximum flexibility, rather than provide objects and methods
for everything I can think of.
In fact, I'm considering doing my own work entirely in non-OOP style and
leaving it open to other people whether to implement OOP score
processing. I haven't decided yet. I may start doing some work in
non-OOP style and see how I like it, and whether I find myself really
yearning for objects and methods... As I said, I'll be making my code
available under the GPL, so anyone who has the skill and desire to chop
it up and re-work it however they see fit would always be able to do
that. So even if I never take an OOP approach, there's no reason someone
else couldn't.
One other objection to the OOP approach that I've thought of is that I'd
kinda like a user of my module to be able to start composing with it
just by having a basic knowledge of "Learning Perl", because that seems
to be one of the most common books people have when learning Perl, and
besides, "Programming Perl" costs ten bucks more. ;) I mention this
because OOP is conspicuously absent from "Learning Perl," except in a
breezy introduction to CGI programming at the end.
> Although these may seem frivolous objections, Perl *is* a hacker
> language, which has the benefit of allowing the programmer to make
> things happen fast. This is a major advantage when programming is
> happening concurrently with composition.
That, in fact, is exactly why I thought of taking the module approach,
rather than writing an interpreter for a newly-invented score format...
I thought, "It would be no more difficult and a lot more flexible to do
this directly in a Perl script." At the time I wasn't even considering
OOP, I was just thinking of allowing for logical tests, iterative and
recursive musical structures, and the like...
> This is not to say "don't use OOP", but rather to say, "think very
> carefully about if you really need it". Some of the data manipulations
> Paul mentioned might well benefit from OOP if they require maintaining
> state information.
Such as keeping track of time? I thought I would do that with an
exported global value so the user would have free reign to f**k it up
however they saw fit at any time.
Or were you thinking of something else?
Argh. The trouble is, if I had any experience with OOP, I would know the
answer to my conundrums, but I don't want to spend the time to learn OOP
if it's not something I'll need right away... and every time I get a
message saying "yes OOP" or "no OOP", I flip-flop... Maybe I should just
start coding some more of the ideas I already have and understand, and
see how I feel about it.
> 1. It would be quite interesting if the resulting package is
> implemented on the WWW such that different algorithms from different
> people could interact to some degree.
Yeek! Are you volunteering to implement this? :)
> 2. Don't necessarily stick to score manipulations. Automatic
> generation of orcs can be equally as interesting. I have a recent
> soundfile processor generator which demonstrates orc generation at
> http://eric.iamas.ac.jp/~eric/CPROC/index.cgi .
Well, that's why I thought of naming the module "Csound:Pscore" rather
than just "Pscore". But I will probably leave it up to others to create
"Csound:Porc" or anything else they can think of.
|