On 09/02/14 14:39, Daniel Zaoui wrote: > On 02/07/2014 12:37 PM, Carsten Haitzler (The Rasterman) wrote: >> On Fri, 07 Feb 2014 10:25:07 +0000 Tom Hacohen >> <[email protected]> said: >> >>> On 07/02/14 00:50, Savio Sena wrote: >>>> "[email protected]" <[email protected]> writes: >>>> >>>>> On 01/29/2014 10:46 PM, Savio Sena wrote: >>>>>> hello everyone, >>>>>> >>>>>> am I late to raise some questions regarding eolian syntax? I've been >>>>>> playing with it lately and I miss some features. Not sure if they are >>>>>> really relevant but I leave for the interested parts to decide. >>>>> You are never late. >>>>>> the point that most caught my attention was that the syntax doesn't >>>>>> make distinction between regular-classes, non-instantiable classes, >>>>>> interfaces and mixins -- at least not yet? shouldn't we have them >>>>>> explicitly stated in the code? >>>>> You are right, it is missing in the language. We can add it easily. >>>>>> similarly it's not clear which class is the parent class and which >>>>>> are >>>>>> classes-extensions. Eo subsystem makes this distinction clearly, as >>>>>> you all probably know: regular classes cannot inherit from neither >>>>>> interfaces nor mixins, etc. that's not explicit in current >>>>>> syntax. we >>>>>> assume the first class in the inheritance list is the parent and >>>>>> subsequent are extensions perhaps? that's a bit confusing anyway. I >>>>>> would expect the language to "tell me" they are completely distinct >>>>>> entities. omitting in this case leads to obscurity. >>>>>> >>>>>> I can think of some other (potentially :)) cool features like *) >>>>>> having support to "#include <some.eo>" instead of counting on a >>>>>> "global database" >>>>> I don't have any problem with that but what is the added value? And do >>>>> you mean there would not be the "global database"? Of course, we can >>>>> improve the parsing phase by parsing the eo files only when a >>>>> change has >>>>> been made and storing the db in some eet file. But for the moment, we >>>>> want to focus on the integration into efl. >>>>> >>>> It would allow the parser to find dependencies without having to >>>> look in >>>> all '.eo' files for instance. I do agree it's more profitable to focus >>>> on other things though... >>>> >>>>> Anyway, we need the "global database" because we want to be able to >>>>> access information on classes in live. For example, you have an IDE >>>>> that >>>>> can tell you to which event a specific widget can register... >>>>>> *) allowing user-defined implementation name instead >>>>>> of only the "default name" (Eg: foobar { impl { >>>>>> _foobar_alternate_impl; } } ) >>>>> Could you be more explicit? >>>> --- foobar.eo ---- >>>> Foobar { >>>> methods { >>>> line_draw { >>>> func { _foobar_dfb_line_draw } >>>> } >>>> } >>>> }; >>> Hmm... This looks like you are exposing internal functions names in the >>> .eo file, that's bad. >>> We should just have a naming convention (added bonus that everyone agree >>> what it's meant to do), and always force it to be called: _<current >>> class name>_<original class name>_line_draw. >>> current class name: the current class name in the eo file, in this >>> example Foobar. >>> original class name: where the function was first defined. >> agreed. this will make for a consistent set of generated code too - >> you know >> exactly what to look for, what it means and where it comes from. > The "user" function name is always an expected one and cannot be > modified from .eo. The only thing you can change from the .eo is the > legacy name and the legacy for the overriding (at least the lexer > supports :-)), as I described in a previous mail.
I was commenting on the suggestion. -- To.m ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
