On Fri, 07 Feb 2014 10:25:07 +0000 Tom Hacohen <tom.haco...@samsung.com> said:
> On 07/02/14 00:50, Savio Sena wrote:
> > "daniel.za...@samsung.com" <daniel.za...@samsung.com> 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
> 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
------------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
