"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 }
}
}
};
The "default-name" would be assumed when func{} is ommited naturally,
and together with a conditional check (something like #ifdef) it would
allow us to choose between multiple implementations. no big deal since
we can make this choice in the C code and that's actually what's already
done, so I think the latter joins the former in terms of priority.
> I don't know if it is related but we are currently working (soon push)
> on a way to permit the developer to define legacy APIs for functions he
> has to implement. It will be useful after the integration, when the
> interfaces will be created, to respect the legacy API.
> For example, if you had file_set in evas_image (legacy:
> evas_image_file_set) and you want now to inherit from some File
> interface, you will indicate you want to implement File_If::file::set
> and that you want a legacy function called evas_image_file_set with
> these parameters/returns.
> File_If::file::set
> {
> legacy evas_image_file_set
> {
> params {
> grp: NULL; /*@ Don't include it in legacy */
> file;
> };
> return Eina_Bool::EINA_TRUE; /*@ Eo doesn't return
> value, but I want my legacy to return something */
> };
> };
>> *) allowing the suppression of
>> variable's name in parameter declaration (Eg: foobar { params { in
>> const void*; } }),
> You mean for regular functions or for implements?
Both perhaps, but originally I was speaking of regular functions.
>> and finally, well, I take the chance to remind
>> jeyzu's wishes of having namespaces and tags? (@jeyzu not sure if I
>> got it correctly but I think by "tags" you mean "aspects" perhaps?
>> that it would be great)
>>
>> I could drop some more thoughts but I'm not sure whether they will
>> still count.
> You can try ;-)
The other ideas are of even minor importance so never mind...
>> From JackDaniel's last e-mail (in Eolian C Generation
>> thread) I think you are on the verge of migration EFL to ".eo", and
>> that's really cool -- I'm also excited and expecting it pretty much,
>> but I ask myself whether it will be feasible to make significant
>> changes in the syntax after that? Don't you guys think we better than
>> should _could_ make this syntax a lot nicer? Perhaps I can help?
> I don't see what you mean. This syntax is so nice I pasted posters in my
> bedroom... Ok I lie. If you have suggestions, you can share them here. I
> can't assure you I will read your mails but you can always try ;-)
>>
Don't get me wrong :-P It's just that nothing is so good that it can't be
improved. nothing but myself of course.. :-P
Kind regards.
--
Savio Sena
<savio.s...@acm.org>
------------------------------------------------------------------------------
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
