I might be misunderstanding the issue, but I'm not sure how this would result from moving to Extension Builder 1.5.
If you want to use two classes with the same name from within one file, then logically you need to refer to at least one of the classes using its fully qualified name (i.e. with com.adobe.indesign/incopy prefix). Otherwise, the compiler wouldn't know which class you were referring to.
If you post a snippet of code that compiled before which now does not compile, maybe that would help me understand
BTW, you can avoid typing your variables by declaring them this way:
var myStory:* = someValue;
Then myStory can have an InCopy or InDesign Story assigned to it. But you lose the advantages of strong typing, like compile-time guarantees that you are accessing properties and methods that actually exist.
This brings up a very good point.
I think it's a mistake to have InDesign and InCopy objects defined as different packages.
InCopy was designed to have the same object model for any features in InDesign that it supports. It was created so you could use the same code for both InDesign and InCopy. This is true both of the (strongly typed) C++ SDK as well as the (weakly typed) ExtendScript interface.
Programming using ActionScript muddles this all up. InDesign and InCopy are considered separate packages and the only way to cleanly program to both is to use ExtendScript calls or throw all type checking to the wind.
I'm not sure exactly what the solution is, but maybe subclassing all InDesign classes with the InCopy ones would be a solution so everything could be automatically upcast. (Probably an awful lot of work to get right though...)
While there is overlap in the InDesign and InCopy DOMs, neither is a subset of the other, so it would probably be non-trivial to establish a common CSAWLib for both. It would be interesting to measure roughly how similar the DOMs are.
"InDesign and InCopy are considered separate packages and the only way to cleanly program to both is to use ExtendScript calls or throw all type checking to the wind."
Would you ever choose to write your scripting code in ES rather than untyped AS? If so, why? Using untyped AS results in very similar code, with some bonuses. For example, you can debug all your extension's code in the same IDE.
Yes. I have used ExtendScript quite a bit. I don't remember off hand why and when I chose to use ExtendScript instead of untyped ActionScript. It's what I did any time I ran into a CSIDE bug. One use case that comes to mind is dealing wih file mainipulation. ExtendScript has a number of helper properties to make accessing files easier (i.e. in the app package, user data, etc.).
It's also WAY faster for me to write simple code in BBEdit rather than fuddling with Extnstion Builder. I know most of the InDesign DOM by heart and I generally don't need code hinting for that (and BBEdit has code hinting for any words you've used in the file). Testing code is almost instant. I can write the code and test that it works instantly. While the "attach" function of Extension Builder is great, it does not come close to the speed of executing uncompiled code...