Re: Where now?

[prev] [thread] [next] [lurker] [Date index for 2003/10/23]

From: Steve Purkis
Subject: Re: Where now?
Date: 12:23 on 23 Oct 2003
On Wednesday, October 22, 2003, at 08:53  pm, Piers Cawley wrote:

> Steve Purkis <spurkis@xxxxx.xxx> writes:
>
>> On Wednesday, October 22, 2003, at 04:04  pm, Mark Fowler wrote:
>>
>>> Okay, so the question is, where are we heading now?
>>
>> Good question.  I did post a short-term plan last week which I'll get
>> started on in my copious amounts of spare time, but AFAIK there are no
>> plans further than that.  Not for lack of ideas, mind you... I've
>> submitted quite a few patches in the past, and I know Piers has a
>> whole stack of them tucked away somewhere.  But as far as I'm
>> concerned Piers is still the lead developer on this project - I've got
>> the go-ahead to do maintenance, but aside from that I think we need
>> some feedback from Piers before we can decide which way to go.
>
> The current problem with Pixie, as I see it, is that the locking
> stuff isn't working very well at all, and without locking Pixie is
> very limited.

Right, that's already #1 in the TODO list.


> I can't remember if we've fixed the object graph stuff to use a
> separate table yet (and if we haven't, we should do...).

It doesn't look like it - I remember we had a good long talk about it 
though.  I'll add it to the list.


> Other plans include getting rid of a few more of the case statements
> that work on the reftype of the object, and switch to using
> polymorphic dispatch with Heritable::Types instead.

Ok, but you'll have to point out which.


> There's also a case to be made for unbundling Pixie::Info as it's a
> handy tool for other things as well I think.

I agree, though I think this is lower priority.  I'm also worried about 
Pixie overwriting info another object has set... maybe if you could 
configure the magic number used?


>>> I can't really do much on Pixie development, it being a little over
>>> my head atm, but what I'd really like to do is start adding
>>> comments to the Pixie source code, and maybe working on the
>>> documentation.
>>>
>>> Does this sound like a good idea?  What's the best way for me to go
>>> about this.  Obviously, I'd really like someone to be checking my
>>> working to make sure my comments aren't completely wrong.
>>
>> I think adding some Pod is a good idea,
>
> More Pod is always a good idea, documenting how to use the bloody 
> thing.

I've got some kicking around somewhere that I'll put in.


>> but I'd go easy on the comments - I know for a fact James prefers
>> self-documenting code, and I assume Piers does too as his code is
>> quite readable.
>
> Why thank you. Generally my gut feeling is that every time I think
> "Maybe I should add a comment here?" I'd be better off working out
> what it is about the code that is hard to understand and rewriting it
> so it's clear.

Yeah, I must admit I'm sold on the idea too.  Only comments I tend to 
put in nowadays are TODO items that I can grep for when I'm feeling 
bored ;-).


>  Admittedly, there are a couple of places where Perl
> makes that very hard to do (I'm thinking particularly of the code
> that does the Data::Dumper -> exec tricks, which uses dynamic scoping
> in slightly weird ways).
>
>> Maybe some design docs would be a better idea?  I'm more than happy
>> to go over things with you, time permitting.  But bear in mind I'm
>> still learning too.
>
> I've been meaning to write something along those lines as a
> presentation at some point, but I've not done it yet. Tuit shortage
> can be a terrible thing.

Well, that's something that Mark and I can work on then.  It will be 
handy for others looking under the hood.

What do you think about the plan I posted the other day?  Here it is 
again, slightly modified:

	1. tag current release as 'dev-22-10-2003' [done]
	2. commit sources of 2.06 as 2.08_01 and go from there. *
	3. update the TODO list
	4. apply http://staging.quiup.com/perl/Pixie-2.06-reconnect-bug.patch
	5. add Mark's recursive structures TODO tests
	6. update docs

The only problem is (2) - I don't want to throw away any work you've 
done, but in order to keep developing on top of the current codebase I 
need to know how stable it is.  It passes all but one (minor) test, but 
I've not yet had the chance to try it out in development.  What do you 
think?

PS: I have a lot of other ideas, but I'll keep them seperate for now.

-Steve

There's stuff above here

Generated at 13:56 on 01 Jul 2004 by mariachi 0.52