Greets,
Logan and I were discussing on IRC that CFC roughly follows a
Model-View-Presenter design pattern[1].
* The parser reads in the source code files and builds a model of the class
hierarchy.
* The "Core" view traverses the model and generates per-class C header
files [plus some stuff].
* The "Perl" view traverses the model and generates Lucy.xs, "typemap",
etc. -- which contain per-class binding code [plus some stuff].
To reflect this architecture, I think it makes sense to do a slight
reorganization of the CFC class hierarchy.
Everything that is used to model the class hierarchy moves under
"Clownfish::CFC::Model":
Clownfish::CFC::Class -> Clownfish::CFC::Model::Class
Clownfish::CFC::CBlock -> Clownfish::CFC::Model::CBlock
Clownfish::CFC::DocuComment -> Clownfish::CFC::Model::DocuComment
Clownfish::CFC::File -> Clownfish::CFC::Model::File
Clownfish::CFC::Function -> Clownfish::CFC::Model::Function
Clownfish::CFC::Hierarchy -> Clownfish::CFC::Model::Hierarchy
Clownfish::CFC::Method -> Clownfish::CFC::Model::Method
Clownfish::CFC::ParamList -> Clownfish::CFC::Model::ParamList
Clownfish::CFC::Parcel -> Clownfish::CFC::Model::Parcel
Clownfish::CFC::Symbol -> Clownfish::CFC::Model::Symbol
Clownfish::CFC::Type -> Clownfish::CFC::Model::Type
Clownfish::CFC::Variable -> Clownfish::CFC::Model::Variable
Then, "Clownfish::CFC::Binding::Perl" gets renamed to
"Clownfish::CFC::View::Perl" and "Clownfish::CFC::Binding::Core" gets renamed
to "Clownfish::CFC::View::Core":
Clownfish::CFC::Binding::Perl -> Clownfish::CFC::View::Perl
Clownfish::CFC::Binding::Perl::Class ->
Clownfish::CFC::View::Perl::Class
Clownfish::CFC::Binding::Perl::Constructor ->
Clownfish::CFC::View::Perl::Constructor
Clownfish::CFC::Binding::Perl::Method ->
Clownfish::CFC::View::Perl::Method
Clownfish::CFC::Binding::Perl::Pod -> Clownfish::CFC::View::Perl::Pod
Clownfish::CFC::Binding::Perl::Subroutine ->
Clownfish::CFC::View::Perl::Subroutine
Clownfish::CFC::Binding::Perl::TypeMap ->
Clownfish::CFC::View::Perl::TypeMap
Clownfish::CFC::Binding::Core -> Clownfish::CFC::View::Core
Clownfish::CFC::Binding::Core::Class -> Clownfish::CFC::View::Core::Class
Clownfish::CFC::Binding::Core::Aliases -> Clownfish::CFC::View::Core::Aliases
Clownfish::CFC::Binding::Core::File -> Clownfish::CFC::View::Core::File
Clownfish::CFC::Binding::Core::Function ->
Clownfish::CFC::View::Core::Function
Clownfish::CFC::Binding::Core::Method -> Clownfish::CFC::View::Core::Method
The punchline:
To add a new host language to Clownfish, write a new View for CFC.
I hope that helps to clarify both how CFC is organized and what it takes to
contribute a new host language.
Marvin Humphrey
[1] CFC is clearly Model-View, but it's not MVC (because it's not
interactive, so there aren't any Controllers). "Presenter" is kinda sorta
right.
