There has been a lot of discussion around adding requires/provides to the platform to ease development around runtime-specific features. Classes would be able to say they provide certain feature(s). Other classes could require those features, and the compiler would warn if a required feature was not available.
One issue with the existing proposal is it doesn't make adding runtime-specific features to existing base classes, (like view) easy. At first blush this doesn't seem so bad. Imagine adding Flash 8 visual effects. With the proposed mechanism developers create a subclass of view that provides a feature, say 'SWFVisualEffects' which in turn requires 'swf8.' The fact 'SWFVisualEffects' can only be added to a subclass of view has all sorts of ramifications to component hierarchies and the like, because components that want to take advantage of new features now.have to extend the new class instead just extending view (like they do already). Ideally we provide a mechanism that allows developers to mix features into existing base classes while still providing warnings where they're unsupported. This could be accomplished by using a variant of traits that supports requires/provides. Right now, adding SWFVisualEffects would require hacking the swf kernel directly and adding the feature into view. This is fine, but it also requires manually adding with warnings for unsupported (non-swf) runtimes. Because of this, I don't think class-based requires/provides gets us a lot of mileage unless it somehow supports mixing into existing base classes (while still providing warnings for non-supported runtimes). For now, we already have conditional compilation for the kernel with 'if ($runtime)' conditionals. Adding requires/provides into traits could provide a much safer (and much more useful) way for developers to add runtime-specific features to the various kernels. This would provide a mechanism that automatically warns when a developer requires features that aren't provided/available, while saving developers from manually writing warnings for other runtimes. What are your thoughts? -- Regards, Max Carlson OpenLaszlo.org _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
