ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tal Liron <...@gigaspaces.com>
Subject Re: ARIA extension mechanism suggestion
Date Tue, 06 Dec 2016 19:59:14 GMT
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