> Also, if a context is something that gets shared throughout plugins, is there any reason not to make it immediately available as a member attribute on the plugin instance? Is it expensive to generate, if the plugin isn't requesting one? If so, you could always make it a context() call or a computed read only property. These things seem to reduce the need of dependency injection.
Thanks, will have a think on this, and get back to you. On 11 August 2015 at 11:26, Justin Israel <[email protected]> wrote: > > On Tue, 11 Aug 2015 10:01 PM Marcus Ottosson <[email protected]> > wrote: > > If the tutorial just said plainly that the goal is to raise any exception > if validation fails, that would be clear enough. > > > Not sure if you missed it, or if you think the current phrasing isn’t > enough, but it does include that any exception is ok. > > “We indicate failure by throwing exceptions of any kind, including > assertions.” > > > http://forums.pyblish.com/t/learning-pyblish-by-example/108/15 > > Do you think there would be any value is splitting up the different types > of processing for clarity? > > Missed it! Sorry. > > > > Funnily enough, this is how things started out. > > https://github.com/pyblish/pyblish/issues/127 > > DI got implemented on a provisional basis primarily to reduce the learning > curve for beginners; not having to explain the Context and Asset concepts > before writing your first plug-in. The hello world example would have been > quite a bit more substantial without it, for example. > Having said that, I am definitely open to alternatives. > > Here’s some of the current logic to preserve. > > Process the worldProcess sections of the world in isolationProcess > sections based on their type > It’s essentially three conflicting requirements that all must align for a > plug-in to run. > > Given a plug-in architecture, where identical plug-ins may run in multiple > environments, such as Maya and Houdini or standalone, how *could* this be > implemented otherwise? > > Well my suggestion doesn't seem to break those goals or make it any less > generic. It takes the same notion that your Asset is already a first class > concept and just makes an explicit implementation hook for it vs a hook > that gets processed a different way. Also, if a context is something that > gets shared throughout plugins, is there any reason not to make it > immediately available as a member attribute on the plugin instance? Is it > expensive to generate, if the plugin isn't requesting one? If so, you could > always make it a context() call or a computed read only property. These > things seem to reduce the need of dependency injection. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOANWQALHbVppMzpuP%3DJ6oHanfzVtGEMLCmM6t9d85iC6g%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOANWQALHbVppMzpuP%3DJ6oHanfzVtGEMLCmM6t9d85iC6g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0f6SULK5iaNYjauPjWgvPmxSGgyd46JARF1KM3V_3r2A%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0f6SULK5iaNYjauPjWgvPmxSGgyd46JARF1KM3V_3r2A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- *Marcus Ottosson* [email protected] -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAWKN75xObzoVtUzt2Lw3TvWMUyXZz3XDgH0wT-smr3sQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
