brief explanation of the new class organizer
Hi, So... this is what I made las days (as a conclusion of many days before): The old class organizer was a mess. Basically, it considered all protocols as strings, and for worst it was arranging them into a flat array. While the array stuff is just an internal problem (objects outside doesn't know how are they managed, and that's good), having protocols-as-strings is essentially bad (no need for explanations about that). The new class organizer just do what is more or less obvious: 1) replaces string protocols for first class instances (now instances of Protocol). 2) internally, manages protocols and methods in protocols in a much better and fashion way. (btw, the implementation was made by Ben, thanks!) the real important part is the point 1. Now we can start to assign real behavior to Protocol, For instance, I will create an ExtensionProcol which will contain a direct pointer to it's real package. That means that we do not need weird computations to get a method extension package (and when the tools allows us, we could get rid off the *Blah). I would like also to be able to have "composite" protocols (like "private"+"accesing"), etc. It will allow a refactor of current RPackage implementation, allowing us to simplify the SystemAnnounce mechanism (and speeding up monticello, if my calculous are fine). And like this, there are still a huge room for improvement, I hope many that I do not even thought about :) cheers, Esteban
On 29 June 2013 00:51, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
So... this is what I made las days (as a conclusion of many days before):
The old class organizer was a mess. Basically, it considered all protocols as strings, and for worst it was arranging them into a flat array. While the array stuff is just an internal problem (objects outside doesn't know how are they managed, and that's good), having protocols-as-strings is essentially bad (no need for explanations about that).
The new class organizer just do what is more or less obvious:
1) replaces string protocols for first class instances (now instances of Protocol). 2) internally, manages protocols and methods in protocols in a much better and fashion way.
(btw, the implementation was made by Ben, thanks!)
the real important part is the point 1. Now we can start to assign real behavior to Protocol, For instance, I will create an ExtensionProcol which will contain a direct pointer to it's real package. That means that we do not need weird computations to get a method extension package (and when the tools allows us, we could get rid off the *Blah). I would like also to be able to have "composite" protocols (like "private"+"accesing"), etc. It will allow a refactor of current RPackage implementation, allowing us to simplify the SystemAnnounce mechanism (and speeding up monticello, if my calculous are fine).
And like this, there are still a huge room for improvement, I hope many that I do not even thought about :)
What strikes me is why such simple concept, which you can express with couple words: "methods in class can have categories", ends up into insanely complex mess of code over multiple layers in system. Anything which puts more order and logic, simplifies these things is welcome. And of course, we cannot see the forest beyond the wall of fallen trees. So we must clean it up first.
cheers, Esteban
-- Best regards, Igor Stasenko.
I love objects but we should consider that they had memory constraints and soon we will have them too because we are starting to have them for Moose ;) Stef
What strikes me is why such simple concept, which you can express with couple words: "methods in class can have categories", ends up into insanely complex mess of code over multiple layers in system. Anything which puts more order and logic, simplifies these things is welcome. And of course, we cannot see the forest beyond the wall of fallen trees. So we must clean it up first.
oh yes!
cheers, Esteban
-- Best regards, Igor Stasenko.
On Jun 29, 2013, at 9:29 AM, stephane ducasse <stephane.ducasse@gmail.com> wrote:
I love objects but we should consider that they had memory constraints and soon we will have them too because we are starting to have them for Moose ;)
then we need a better vm/object space/whatever... not to strip down the objects :) Esteban
Stef
What strikes me is why such simple concept, which you can express with couple words: "methods in class can have categories", ends up into insanely complex mess of code over multiple layers in system. Anything which puts more order and logic, simplifies these things is welcome. And of course, we cannot see the forest beyond the wall of fallen trees. So we must clean it up first.
oh yes!
cheers, Esteban
-- Best regards, Igor Stasenko.
participants (3)
-
Esteban Lorenzano -
Igor Stasenko -
stephane ducasse