ARIA extension mechanism suggestion

[Dan Kilman <da...@gigaspaces.com>]

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.

Re: ARIA extension mechanism suggestion

[Ran Ziv <ra...@gigaspaces.com>]

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 <ta...@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 <da...@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.
> >
>

Re: ARIA extension mechanism suggestion

[Tal Liron <ta...@gigaspaces.com>]

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 <da...@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.
>