On 5/6/16, 3:07 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: > >3) Do we know of any other Maven-built code bases that use conditional >compilation and offer slightly different APIs for downstream modules? > >I don't know of any, but I do know projects that produce different output >from the same input ... if you look at GWT projects for example. Here >part of the code is compiled to java and another is compiled to >JavaScript but everything is written in Java. I probably don't know of >any, cause it's probably not the question "how do we structure such a >project?" which we should ask but "why do we need different APIs in our >libraries depending on the output?".
Because I don't think we should preclude propagation of platform APIs downstream. In my experience, people are always looking for better performance, and sometimes an optimization involves breaking some encapsulation boundary. I am liking the way Maven makes you TRY to conform to certain patterns, but I don't think innovation MUST be forced to fit inside a set of rules. That's why the phrase "Think outside the box" is a good one. >I am proposing to make the libraries, like Core, self contained so they >have the same API no matter what output they are needed for. For example >IUIBase ... why do we need to have different return types for get >element? Sure the implementation might be different, but then I would >suggest to introduce an intermediate layer that is mapped to >IFlexJSElement and WrappedHTMLElement. This way we don't need conditional >compilation everywhere IUIBase.element is accessed. I think that's an >implementation detail only Core should worry about and all the downstream >Libraries should only know "IElement" (IElement being the non existing >element abstraction). There could certainly be places where it will be worth doing things like this. None of our APIs are final, IMO. >This would also improve IDE support as the IDE doesn't have to know about >conditional compilation. Currently IntelliJ is completely full of red >code, cause it doesn't really know what to do with it. Also SonarQube >will definitely not know what to do. That's an IDE problem. Conditional Compilation is a language feature. We should be allowed to use it. Even Wikipedia says that conditional compilation is often used for multi-platform code. That's what we are doing. >If we were to abstract the implementation details, we only need the >externs for Pure JavaScript libraries and for those the externs approach >is absolutely valid. So If you ask me for my vote on this it's >deffinitels: "Cleanly abstract the implementation and eliminate the need >to generate two types of artifacts from one code base". I know this is >work, it's not glorious work you get Aaaaahs and Ooooohs at conferences >for, but it's work that just need to be done. I am willing to work on >this, but I'm not willing to work on this all on my own and I'm not >willing to waste my time in continuing to support sloppy design work. There are definitely places where the code is sloppy, but I'm not convinced that having internal plumbing within the SWC for a platform is "sloppy". Yes in theory you can create abstractions and make everybody else live on top of it, but abstractions usually cost you in code size and cpu cycles. In the end, having your app perform well will bring in more customers than whether we used Maven for every step of the build. I was wondering if using the name "externs" for the SWCs that Ant currently puts in frameworks/externs is causing some confusion since they aren't quite the same as the externs SWCs in flex-falcon. I called them the same thing since both are used on the external-library-path, but really, the flex-asjs externs SWCs are internal JS APIs, so maybe those SWCs should be given a classifier like "JS_INTERNAL_API" so the SWC is called Core_JS_INTERNAL_API.swc. And that's why I was thinking there should be a separate folder structure for it, with its own build.xml, pom.xml, and FB project files. I might still create that tree just to manage the FB project files. There is already a frameworks/js folder. Maybe I would create a frameworks/js/projects folder with children like Core, HTML, etc. Again, the "strange" thing would be that there would not be any source in those folders: their source-paths would use relative paths back to frameworks/projects/Core, HTML, etc. Thoughts? -Alex
