On Thu, 19 Jun 2014 10:32:45 -0300 Felipe Magno de Almeida <felipe.m.alme...@gmail.com> said:
> On Thu, Jun 19, 2014 at 10:18 AM, Daniel Kolesa <quake...@gmail.com> wrote: > > 2014-06-19 14:02 GMT+01:00 Tom Hacohen <tom.haco...@samsung.com>: > > > >> Hey, > > Hello Tom, > > [snip] > > >> We are working on the Eo EFL API, making it clean, consistent, and > >> predictable. This work covers sharing similar interfaces among similar > >> classes all over the EFL, adding Eo API to things that are not covered > >> by Eo at the moment and should be, and probably in the future also > >> fixing some broken API we might have lingering around. > > [snip] > > > It's pretty clear that we need something like this. But I fear that having > > lots of "global" efl_ prefixed funcs will lead to interface creep, not > > something we necessarily need; also, it means we'll have to split these > > into many different interfaces - we will want to categorize these somehow, > > instead of shoving everything into one. > > I don't think they are the same function. To say that they set a file > is way too simple. Each function sets for a different purpose and that > must be documented. They are different functions and in a OO (I don't > even like OO, but just to use as an example that not even OO-people > would do this) these functions wouldn't be related at all, they > wouldn't override each other or anything. in this case, they should conceptually do the same job. take the object and point it at a file to deal with. it may be for reading. it may be for writing. how it decodes etc. may vary, but the primary obvious and expected behavior should be the same, otherwise don't use the api. but indeed we do need a way to document overridden methods if they do something differently enough worth documenting. we have another big problem which is documentation across multiple languages too - where the docs for a function (method) or property (maybe 2 funcs) needs to be able to differentiate between core "language agnostic" docs and "language specific paragraphs". it's a problem that, as best i know of, to date, has never been solved in any doc tool i know of. > The problem with prefix is just that in C we don't have overload > resolution, so we pay by prefixing a namespace to functions instead of > relying on the argument's types. > > I'm not against making the prefixing smaller and easier to use, but > those functions shouldn't even be considered global. If something like > this goes forward we should think as overloading, and with > overloading, there must be a solution with reference documentation as > well. > > > This is all something that we need to think about... > > I agree. > > >> -- > >> Tom. > > Regards, > -- > Felipe Magno de Almeida > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
