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
>> <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.
> 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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
