[MacRuby-devel] mappings, tags, etc.

Rich Morin rdm at cfcl.com
Wed Dec 3 11:02:15 PST 2008


At 00:46 -0800 12/3/08, Jordan K. Hubbard wrote:
> If HC enables the quick and easy creation of modules/frameworks/
> softwareICs/callemwhateveryoulike to such an extent that we start
> seeing any sort of proliferation of them then "packaging and
> general husbandry" becomes the first and most immediate concern.

Indeed, it's not at all clear what kinds of contributions to expect,
nor whether a single approach will be suitable for all types.  The
CPAN, for example, has never been very hospitable to applications
(although some alternatives have been tried).


> Maybe RubyGems provides the appropriate packaging  abstraction
> already, or perhaps that's too coarse-grained (I have no idea
> how "GEM space" is partitioned or otherwise managed, but I'd
> imagine there's a limit somewhere) and we need gem fragments
> (splinters?) that HC supports for itself.  I dunno.

The gem naming system is pretty simplistic; the Merb folks have been
running into that head-on, because they use RubyGems for everything.
So, we are seeing awkward constructions like merb-slice-wombat.

I can't imagine a RubyGems naming convention that could comfortably
handle arbitrary HC mappings.  More to the point, I'd rather not deal
with tracking such a "splintered" collection of gems in my apps.

The CPAN uses a hierarchical namespace with some success; maybe we
should look in that direction.  In many cases, the top level can be
defined by the OSX framework (etc) that the mapping uses.  However,
I could also imagine a need for mappings that cross OSX boundaries.

If we had a convenient way of "tagging" the mappings (eg, in terms
of the OSX methods they wrap), we could help developers locate the
mappings which are most likely to be relevant to them...

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development


More information about the MacRuby-devel mailing list