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.
>> 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
>>
>
------------------------------------------------------------------------------
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
