From: Abraham E. <abe...@gm...> - 2005-07-01 03:32:31
|
> So the version in darcs on your site is the latest version of your code > I assume. http://ofb.net/~abe/darcs/cairo Yes, this is correct. > Actually, Paolo and I were reviewing the differences in the two > attributes modules yesterday and came to the conclusion that they are > very similar and could be merged and shared quite easily. >=20 > There are some internal implementation difference that do not really > affect the user api, eg you use classes for readable and writeable > attributes whereas we represent those slightly differently. Then your > library has the concept of a 'global' attribute by making the object > just the unit type (). This is something that we can add in the same > way. Similiarly, your library is generalsied over the monad. Our current > version uses just the IO monad but it could easily be paramaterised over > the monad in the same way that your library does. Are you looking at the current version of Data.Attribute (http://ofb.net/~abe/darcs/attribute)? Other projects of mine have driven it to evolve, and I haven't updated hscairo to match. For example, attributes are no longer parameterized on object type; instead, assignment (=3D: and friends) take a function from the object type to the attribute type. This means that global attributes don't have the unneeded '()' in the definition, and in general allows for cleaner and more functional usage. I'm not sure how these changes impact your assessment, but I very much hope that the two systems can be merged. > The only remaining difference is in the names of the operators. I'd > rather stick with the names we've got ':=3D' since it is the same as what > wxWidgets and hs-fltk use. I'm fine with the renaming. Originally I used '=3D:' when the module was pure haskell98 to avoid existential types, but other things have since broken haskell98 compatibility. > Also as a longer term packaging goal it'd be great to share the > Data.Attributes implementation between Gtk2Hs and hscairo probably as a > seperate 'cabalised' package. Yes, I would very much like this as well. One of my motivations for writing Data.Attribute was seeing all the various incompatible implementations of the same sort of system (Gtk2Hs, HOpenGL, etc.) > So how about this for a short term and long term plan for packaging: >=20 > Short term: > To make Paolo's life easier we have him host the darcs repo for his > hscairo fork (possibly using Gtk2Hs web space) and have it depend on > Gtk2Hs and use the attributes API that is part of the Gtk2Hs glib > package (we would obviously have to generalise it to accomodate the > needs of hscairo). >=20 > Longer term: > Update the Data.Attributes module to an interface and implementation > that can be shared by Gtk2Hs and hscairo. Distribute hscairo seperately, > depending only on the Data.Attributes package (as it is now) and have > Gtk2Hs depend on hscairo, and have both projects packaged and > distributed seperately (though we would probably need to coordinate > releases to ensure compatability). This looks like an excellent plan. > I can send a seperate email describing in more detail the changes we > would need to make to be able to share the Data.Attributes module, > including an initial implementation for review. Please do. Abe |