Also, when you have a fixed number of types, I would use an
enumeration for the type rather than a string. It's clearer,
prevents abuse and mistyping, and mentions the possible values
automatically in the scripting dict.
So it turns out this is not actually possible. When you have both
an enumerator named "book" and a class named "book," AppleScript
interprets the word "book" as a class name and refuses to convert
it into a constant. Thus, it seems, we can either have subclasses
or have enumerated types, but not both. Hence, the use of strings.
Given time constraints, I think I'm going to have to abandon the
subclasses and just have a single "medium" type, as unfortunate as
that will be...
Mike, terminology conflicts can be a pain. If you search the archives
you'll see past instances.
However, script writers are going to expect that your terminology to
be meet certain expectations.
make new media with properties {type: "book"}
just feels wrong, when it should in fact be
make new book
Having an enumeration named book and a class named book can run you
into trouble. (They have to use the same four character code, and
even then in certain cases you'll get funky object specifiers, so it
is best to be avoided.)
But do you even really need to have the book enumeration?
In the terminology if you have a media object, and a book object, the
user should be able to access them specifically or generically (I
realize this is the other question you asked) and as long as the
objects specify them selves, use the class operator to determine what
kind they are. In that case, having a type property of media which
returns an enumerated value "book" is not necessary; and isn't the
norm for how things work.
