I suggest that someone should use the tools/dev/parrot_api.pl
and clean up the binary interface Parrot is currently offering.
As in: what interfaces the Parrot library exposes to the outside
world.
While Parrot is quite clean (as compared with Perl 5, say...),
there are still hundreds of functions (that do not have Parrot_
or similar distinguishing prefix), and few dozen modifiable data
items (which are bad for things like multithreading, and which offer
nasty globally modifiable state.)
A good rule to follow would be: expose as little ABI (or API)
as you can get away with. You can always expose more later,
but you cannot "expose less" of what you once let out of the gate.
I know Parrot is still in the early 0.x phases, but better
get the policy right from the beginning.
I think this TODO item should actually be part of
"#34325: [TODO] parrot release 0.2.0".
--
Jarkko Hietaniemi <j...@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
> I suggest that someone should use the tools/dev/parrot_api.pl
Yes please.
> I think this TODO item should actually be part of
> "#34325: [TODO] parrot release 0.2.0".
Yep. My "steps towards 0.2.0..." isn't in any way ment to be complete.
Cleaning up the API and properly export it for e.g. Win32 is definitely
one of the desired goals for 0.2.0
Thanks for the reminder,
leo
I've marked this ticket as such in RT, but I'd like to suggest that
these TODO items become *requirements* for releases, and not "desired
goals". There's no real point in having a plan if you don't follow it,
and this could provide some direction (always a good thing).
--
matt diephouse
http://matt.diephouse.com
> I've marked this ticket as such in RT, but I'd like to suggest that
> these TODO items become *requirements* for releases, and not "desired
> goals". There's no real point in having a plan if you don't follow it,
> and this could provide some direction (always a good thing).
Well, we can't enforce that it did happen in a reasonable time frame. If
there are other important milestones reached, there will be a major
release.
leo
That sounds a bit naive. The benefit of a plan is primarily in the act
of making it (it forces you to think about what you want to do). The
secondary benefit comes when you track how actual progress deviates from
the plan: this lets you think about how/why your plan wasn't accurate.
Following a plan gives very little benefit. If the plan is accurate,
then people will naturally follow it, without needing to be told. They
may follow "priorities" (which may derived from the act of planning),
but that's a subtly different thing.
Dave.
It's nice to see so many professional project managers signing up :-)