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. > This essentially forces a nice convention all around our code, is super > easy to do, doesn't expose extra internal bits in the .eo files, and > saves us some typing. > > I'd hate having the "func {}" thing. 100% agree. > -- > Tom. > > > > ------------------------------------------------------------------------------ > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
