ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ran Ziv <...@gigaspaces.com>
Subject Re: ARIA extension mechanism suggestion
Date Wed, 07 Dec 2016 11:53:37 GMT
I agree it's more neatly organized when the extension methods are under a
single class.
I think the decorator itself should also include the relevant namespace for
the extension (i.e. in this case it's a parser extension, so an
"@aria.extension.parser" decorator is probably what I'd use. It also makes
things simpler on the consumption side of things).


On Tue, Dec 6, 2016 at 9:59 PM, Tal Liron <tal@gigaspaces.com> wrote:

> Thanks for this work, Dan.
>
> My thinking is that function decorators are not best in this case.
> Decorators add a lot of debugging difficulties in Python as its hard to
> follow function calls and their names get changed along the way.
>
> I think it would be better to have the same function names for these hooks,
> which means a general "interface" class that's registered once. In my
> parser code I used a common base class, but I can see this as unnecessary.
> What we could do instead is have a class decorator.
>
> I suggest something like this:
>
> @aria.extension(optional args)
> class MyAriaExtension(object):
>   def get_presenter_class(self):
>      return ...
>   def get_presenter_class(self):
>      return ...
>
> This is nice because it keeps all the extension APIs in one place and makes
> it easy to follow with a debugger.
>
> The extension caller would revert to some default behavior is the extension
> hook does not exist.
>
>
> On Tue, Dec 6, 2016 at 6:09 AM, Dan Kilman <dank@gigaspaces.com> wrote:
>
> > Hi all!
> >
> > I'm putting a link to a gist that contains my suggestion of an extension
> > mechanism that
> > will be used in ARIA by different parts (CLI, parser)
> >
> > https://gist.github.com/dankilman/e7b23691e4c31d8ac6dd04ec291573ed
> >
> > You input on this is more than welcome.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message