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.
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?
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?
> 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 ;-)
> 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 ;-)
>
> Kind regards.
>
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
