On Fri, Dec 26, 2008 at 3:40 PM, James Harkins
<jamshark70@xxxxxxxxx> wrote:
On Fri, Dec 26, 2008 at 10:12 AM, Eric Lyon <
audiodidact@xxxxxxxxx> wrote:
> It's easy enough to fix, but perhaps it would be better if, upon
> encountering dupli
cate class definitions, SC were to simply print a warning,
> and then choose one of the two class files, rather than render the entire
> application inoperable.
not compiling, but I think the current behavior is reasonable. If
there's a discrepancy, it's better policy (more stable) to insist on
the discrepancy being fixed before continuing. You might have two
classes with the same name that do totally different things. The
compiler can't magically resolve that.
I disagree. It's a catastrophic response to a possibly minor problem - like designing a car so that the engine refuses to start unless your seat-belt is fastened. Maybe that is a good idea for car design, but for software, I prefer a "give me enough rope" approach to the "nanny-state" solution that is currently in place. And most probably the clash will be introduced by someone else's quark or some update in a class that I might not even care about. For all I know the clash that I reported might be between identical code files where a 3rd party class has been merged into the main distribution.
That's not to mention the thorny problems of choosing one class file
over another. Should it prefer files in ./SCClassLibrary over
extension directories? There could be duplicates in two different
extension libraries... which is "more important"? (Hint: No matter
which policy you choose, somebody somewhere will be unhappy with it.)
That's less of a problem, because if there's a class clash, automatically resolving it is a stopgap to assure that the SC program as a whole can run. Once the clash is announced by a warning message, it's the user's responsibility to resolve it (if s/he cares to).
Eric