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. > We like to take pride in the stability of our CVS, any random snapshot > is likely to just compile and work. We have a reputation amongst our > users for having an unreleased, constantly changing code base that is > more stable and usable than v3.5 releases of other projects. This is > why some Linux distros are not only happy to use E17 as an officially > supported WM, they make loud noise about using E17. > > Whatever development environment you use, they often come with tools > that make these sort of fixes easy. It's not rocket science, it's > business as usual computer science. Computer programmers change APIs > all the time, and we have written many tools to help with this change > process. Please use them. as above - there is a COST. i can and do break api's - but i do not do it unless i REALLY NEED TO. i will advocate doing things in ways that do not break api's. breaking semantics (not just the rigid api itself) is also bad - but not quite as bad as things till compile and probably work - but they work a "little differently". > > End of rant. > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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
