But doesn't this simply result in abstraction which, in the very theory of the process, is just wrapping one function in another.
One minute you were suggesting that we remove the dynlayer abstration and manipulate the layers directly, next you want to add extra levels of code. It is becoming confusing with the two theories coming from the same person. I think we need to focus on getting the existing objects / structures working in a fashion that allows for the project to grow. Instead of constantly going back to the drawing board. If you want to rebuild the structure, do so as a side project in your spare time and come back when you have a more substantial case. All this speculation is just clouding the issue. And before people start flaming me and accusing my off saying one thing and doing another, I have done exactly what I expect of others. I have in no way forced my version onto the developers / users of the DynAPI. Nore have I requested that they move away from the standard version. I have no problem with people developing a customised version. But it is a bit hard to expect other developers to make the jump to a new structure without seeing it in action. As someone who has done the whole restructure process and knows how long it takes, it is almost impossible to redesign the structure (either internal or external) and still keep the same functionality and ease of use. It all comes down to a balance. I had the time and was willing to put the hours in. However, it took almost 4 months of work to get the code back up to the same level as te official version. If anyone wants to reduce this time by using additional developers, by all means, go ahead. But you need to give more info / examples of what you want. The DynAPI is too developed and too established to start redesigning on a whim. -- Michael Pemberton [EMAIL PROTECTED] ICQ: 12107010 _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/[email protected]/
