[wp-hackers] Adding wp-includes/class folder

[jacobsantos at branson.com]

Makes sense. When I submit the patch for XMLRPC, I'll update it to 
exclude the changes I made to IXR.

I think at this moment the least amount of restructuring as possible is 
needed. So while I also think the Factory model would be nice in several 
areas. If the devs would accept a simplified version, it would be easier 
to get on board with the more complex restructuring.

I think the Database Access Abstraction Layer is another good candidate 
for the factory model, even with it technically being an external 
library. However, this implies more work and I've yet to figure out a 
good way to think about a easy way to get around the differences of SQL.

Ideas

1. Have a object for each SQL platform supported with only SQL. I've 
decided against this.
2. Have functions that returns just the SQL for that API. Just as bad as 1.
3. XML? Eh.

Probably just keep it as it is for the SQL, but allow for the query 
layer to be updated.

Jacob Santos

Stephane Daury wrote:
>
> 3rd party libs are always an issue in this kind of restructuration.
>
> For this reason, I always make a habit of having all 3rd party 
> dependencies in their own specific subtree so that there is a clear 
> distinction and do not feel compelled to apply my convention to these 
> pieces. Then I have a simple wrapper implementing/including the 3rd 
> party software, which itself respects the convention.
>
> A side advantage is that the wrapper allows me (very often) to switch 
> the said 3rd party software to another provider when a better solution 
> comes along or allow library choices when available (such as different 
> caching mechanisms, locale support systems, etc).
>
> I know it sounds heavy, but it pays off in flexibility in the long term.
>
> Stephane
>
>
>
> On Aug 31, 2007, at 10:02, Kimmo Suominen wrote:
>
>> On Fri, Aug 31, 2007 at 02:13:41PM +0100, Peter Westwood wrote:
>>>
>>> For things like IXR / POP3 support / PHPMailer - splitting the classes
>>> out is a really bad plan IMHO - they are external libraries that we
>>> include and we need an easy way of diffing between our version (with
>>> some patches) and the upstream version so as to make it easy to pull in
>>> updates.
>>
>> Similarly renames and code shuffling between files easily creates
>> a lot of extra work, as svn isn't smart enough to merge changes
>> from changed files into the new file (let alone the new location
>> of a file fragment, e.g. when a function is moved to another file).
>>
>> Such changes shouldn't be made lightly, in my very humble opinion.
>>
>> Best regards,
>> + Kimmo
>>
>> P.S. Any svk gurus around willing to tell me what I'm doing wrong?
>> -- 
>> <A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>
>