On Mon, 16 Jul 2007 23:03:33 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote:
> On Tue, 10 Jul 2007 08:40:24 +1000 David Seikel <[EMAIL PROTECTED]> > babbled: > > > This is a pet peeve of mine, so I'll just vent some steam. B-) > > > > On Mon, 9 Jul 2007 01:50:44 +0300 "Hisham Mardam Bey" > > <[EMAIL PROTECTED]> wrote: > > > > > So what if we have an API break? We can take care of it - we have > > > not even made a stable release yet! If a developer takes the time > > > to improve something that no one else has the time (or will) to > > > work on, and it results in an API break, lets get his code into > > > CVS (on the condition that he fixes the core libraries and > > > applications that are affected). What are the core libraries and > > > applications? Thats a good question that we need to answer as a > > > community and as a group of developers. > > > > I've brought up the topic before, particularly with respect to ETK > > and EWL. Those that break an API in E's CVS should fix everything > > in E's CVS that gets broken by it. Despite all protestations to > > the contrary, it's not that hard. Whenever I've brought up this > > topic before, it's always "it's too hard, there are thousands of > > things to change". After getting annoyed and fixing things myself, > > I usually find the fixes are trivial. > > it's not hard - if you have mountains of spare time. change 1 very > commonly used function to have different (more less, changed) > parameters - and boom you may need to find 100's of instances - > across 10's of directories or 100's. and edit them all. changing 1 > small thing because you feel like it may take 10 minutes in evas or > edje or ecore - but then sink hours across everything else to fix it. > it is NOT easy to break an api. not once it is in use - especially > heavy use. every api break needs to be weighed up and considered. > > > If it's trivial for me, a person that didn't change the API and has > > to figure things out by careful inspection of the commit email, > > then it will be even more trivial for the person that changed the > > API, as they will already understand the change. > > again - see above. the person breaking the api may be able to change > it easily > - in principle, but in practice it could be 5hrs of api fixes for 10 > mins of acutal api break. My point is that in reality it usually is just a few minutes work, even with primitive manual tools. With proper refactoring tools, it's just a mouse click or three. Lots of IDEs have proper refactoring tools. The API break that needs hours of fixing things hardly ever happens. What commonly happens is that an API is broken, and a few things go for weeks being broken that only take a minute or two each to fix.
signature.asc
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
