Latest PIDA Release - Explicit is better than implicit
Well, congratulations to all the developers, we have just released PIDA 0.5. This release is probably the most significant in that we are finally happy with the core architecture.
Although not everyone was agreed on how to do it, I was quite strict and employed this famous rule of thumb:
Explicit is better than implicit
And honestly, it really is. Previous versions of PIDA were dogged by overuse of magic and abuse of the declarative class syntax (and the associated metaclass madness). This caused one major problem. Things that should have been happening at runtime were happening at class declaration time. Which is fine if you can get your brain around it, but really evil when you want to reverse these things.
As an example, PIDA services (and a service is like a plugin) can basically do anything to the application (a bit like the Eclipse plugin architecture - but we think better!). One example of this "doing anything" is to define global configuration options.
In PIDA 0.4 options where defined something like:
When the service was instantiated, some metaclass magic would convert the option definition to options objects which could be used elsewhere in the application. This kind of declarative style has been popularised with ORM's like SQLObject, Django and extensions for SQLAlchemy, and is pretty nice to use and read.
The problem with it is that once options have been created and magically sent off into the ether, they are there, and removing them involves some similarly evil trickery. For this reason services were almost impossible to load at runtime and moreover almost impossible to unload at runtime.
So for 0.5 we did away with the class declarative syntax (with some annoyance from some of the developers) and replaced it with something more like:
Ok, so this is a bit more annoying to write, but I think one can get used to it easily enough. Clever readers will notice that the documentation string is now translatable. And the major bonus is that because this is not happening in the ether, self.remove_option() is an obvious possibility.
Unfortunately, implementing this for the various pluggable components of PIDA: Options, Events, Commands, Actions, Contexts, Views required a complete rewrite. They say never rewrite an application, but we have done, and with great success.
So, since this blog is just an obvious advertisement for a release, please visit the website at http://pida.co.uk/, and download the latest version. The feature-improvement is huge, and we are one step closer to bringing the world the One True IDE (tm). We also have Emacs support in this release which should appeal to some people.
Although not everyone was agreed on how to do it, I was quite strict and employed this famous rule of thumb:
Explicit is better than implicit
And honestly, it really is. Previous versions of PIDA were dogged by overuse of magic and abuse of the declarative class syntax (and the associated metaclass madness). This caused one major problem. Things that should have been happening at runtime were happening at class declaration time. Which is fine if you can get your brain around it, but really evil when you want to reverse these things.
As an example, PIDA services (and a service is like a plugin) can basically do anything to the application (a bit like the Eclipse plugin architecture - but we think better!). One example of this "doing anything" is to define global configuration options.
In PIDA 0.4 options where defined something like:
class MyService:
class Options:
class Opt1:
"""Opt1 documentation"""
type = STRING
default = 'Opt1'
When the service was instantiated, some metaclass magic would convert the option definition to options objects which could be used elsewhere in the application. This kind of declarative style has been popularised with ORM's like SQLObject, Django and extensions for SQLAlchemy, and is pretty nice to use and read.
The problem with it is that once options have been created and magically sent off into the ether, they are there, and removing them involves some similarly evil trickery. For this reason services were almost impossible to load at runtime and moreover almost impossible to unload at runtime.
So for 0.5 we did away with the class declarative syntax (with some annoyance from some of the developers) and replaced it with something more like:
self.add_option(
name='Opt 1',
type=STRING,
default='Opt1',
doc = _('Documentation for opt1')
)
Ok, so this is a bit more annoying to write, but I think one can get used to it easily enough. Clever readers will notice that the documentation string is now translatable. And the major bonus is that because this is not happening in the ether, self.remove_option() is an obvious possibility.
Unfortunately, implementing this for the various pluggable components of PIDA: Options, Events, Commands, Actions, Contexts, Views required a complete rewrite. They say never rewrite an application, but we have done, and with great success.
So, since this blog is just an obvious advertisement for a release, please visit the website at http://pida.co.uk/, and download the latest version. The feature-improvement is huge, and we are one step closer to bringing the world the One True IDE (tm). We also have Emacs support in this release which should appeal to some people.
