[sldev] Source reorganization needed

[Dale Glass]

On Tue, Aug 28, 2007 at 11:02:28AM -0400, Michael Miller wrote:
> 3. A major lack of documentation. There's no document that explains
> what each file does. This is unquestionably necessary for source code
> of this size, so someone who is new to the code can get acquainted
> easily.
Got to agree with this one, although to LL's credit, it's usually very
obvious what a function does. Commenting a function:
// Requests information on the object's properties

isn't terribly useful. Now if you find some obscure place, I think
posting a link to the list would be good.

> Personally, I'd say either MAJOR code reorganization with massive
> amounts of documentation(i.e. documentation for every function in
> every file detailing arguments and returns) or entire rewrite of the
> code from the ground up(probably too expensive to happen). To me,
> Second Life looks like a hacked-together piece of software that won't
> sustain itself in the long run. Something needs to be done about it.

I'm reluctant to comment on the rest of the issues, because that would
bring the conversation in a different direction from what I intended. Not
that it's a bad thing to discuss, but IMO you're mostly bringing up
different issues from what I had in mind.

My specific problem is that the current code organization makes certain
assumptions that make plugins and patches somewhat harder than they
should be. 

For example, I'm coding something and want to get information on an 
object.

So I grep the source a bit and see that the selection manager sends the
right message. But to twist the selection manager into requesting info
on the object that interests me is weird, and could well interfer with
its primary function.

Since good programming practice says that if you're going to duplicate
something you should make a function with it, that'd be the right thing
to do. But where to place it?

Should I tack this on to LLViewerObject for example? But it's not no
getOwner() method. Should I add one? Maybe it's a design decision that
an object's owner is supposed to be requested when needed and not
remebered?

For things like the friends floater what would be needed is to split it
into two parts: the parts that does the actual managing of the friends
list, and the UI to it. 

But that's again a step towards a "librarization" of the networking
parts of the SL code, and I don't think it can be done well without
coming up with a coherent design for all of it.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070828/f07867b3/attachment.pgp