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