On Fri, 18 Sep 2015 13:00:50 +0300 Vyacheslav Reutskiy <reutskiy....@gmail.com> wrote:
> Hello > > On Fri, Sep 18, 2015 at 11:58 AM, Stefan Schmidt > <ste...@osg.samsung.com> wrote: > > > Hello. > > > > On 18/09/15 10:41, Vyacheslav Reutskiy wrote: > > > Really, I don't like to a remove API's, but they have not body. > > > > > > Stub function as implementation - we can do it, but it's smell as > > > an attempt to revive the corpse. I would not have left this API's, > > > but If some one say that they need and should stay, I revert > > > commit and make new, where it marked as deprecated and have a some > > > stub. > > > > Lets wait some time before reverting anything here. I want to hear > > at least an opinion from Cedric on this. Guess raster might also > > have something to add. > > > > Of course wait! I'm not going to do revert, without others opinions How is this suitable for keeping around at all if it never had any functionality behind it? Accidental NOPs don't really need to be deprecated, they don't do anything, so no one is relying on them to do anything. Any new thing based on ector might very well have nothing in common with the ancient gradient stuff. Don't think it would be a good idea to try to squeeze new stuff into ancient API that got removed. Not to mention that in EFL, it's traditional to throw out old stuff, and replace it with completely new stuff. It's only left over crap that never did anything, my vote is to just remove it. The result of just removing it - a very few compile time errors that are easily fixed, remove the function calls that didn't do anything anyway. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
