With regard to difficulty, I was mainly thinking about the issue of dynamic linking of precompiled code which Nicolas says is more difficult than it might appear. The idea of having both compiled and uncompiled code is very appealing as it is just like java, and alot of us are very comfortable with that. But I have no understanding of the complexities that Nicolas is refering to. I just know I love the idea of a nearly exactly (where appropriate) equivalent of the jar file.
Regards, Hank On 1/18/06, Martin Wood <[EMAIL PROTECTED]> wrote: > > Now how easy/difficult to do is a different matter :) > > :) thats true... > > thinking about it some more handling the concept consists of 2 distinct > tasks > > 1. Building the SWC / FAR > > 2. Compiling / Referencing the SWC / FAR > > Building is fairly straightforward, it can be just a zip with > > 1. SWF File > 2. Either source code or 'header files' (the dynamic intrinsic > declarations)..or even both. > 3. Optional manifest file. > > The manifest file could be useful for a quick way to determine the > contents of the zip without exploding the whole thing. > > Im not suggesting that its necessarily wise to copy the JAR style > wholesale, but it would be stupid not to consider the pros and cons of > an already existing and well used solution. > > The second part of actually using the packed file will depend on what > the tool is. A compiler will have different needs to an IDE and how best > to integrate this is a whole set of other discussions. :) > > Although the usage of the files will have some impact on what will go > inside them to make integration easier.. > > e.g. do you always include the header file style declarations even if > there is source code. One advantage is that it provides a top level view > of the API defined by the code / swf and the compiler / IDE wont have to > parse the complete source tree just to gain type / declaration information. > > just some more ideas, it will be interesting to see where we end up :) > > martin. > > > > Regards > > Hank > > > > On 1/18/06, Martin Wood <[EMAIL PROTECTED]> wrote: > >> I think a conjunction of the two ideas would be good. > >> > >> When using jar's you can also provide the source code, this is useful > >> when you are using the jar within a project and can then examine the > >> code of the library you are using. I use this all the time when > >> developing RCP (Eclipse Rich Client Platform) applications as its > >> quicker to just highlight a type or a call and hit 'Open Declaration' to > >> read the source comments without having to do a mental context switch > >> into the API docs. > >> > >> So it maybe worth considering enhancing the SWC concept to include the > >> FAR idea, something like a 'src' folder inside the SWC would be enough. > >> > >> Of course this would rely on tools to support the option and be able to > >> make use of it. > >> > >> An option for MTASC / HamTASC like : > >> > >> mtasc -swc myLib.swc -includeSource ...other args... > >> > >> then we just need the various editors to support the use of the swc > >> option when invoking MTASC and using them as 'project references' :) > >> > >> If a complete scheme like this could be worked out I think it would be > >> fantastic, one of the most difficult things for me when developing flash > >> is keeping my libraries and classpaths organised. For java its easy, i > >> just stick my jar's in a lib folder and forget about them. > >> > >> martin. > > > > -- > Martin Wood > > http://relivethefuture.com/choronzon > > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
