Hi Savio,
Concerning the class type, I hesitate between:
- Elm_Button as Regular {...
- Elm_Button {
class_type: Regular
Well, here I give regular as example even if I think it should be the
default type but it is just for the example.
I prefer the first one.
More, we have four types that could be Regular, Mixin, Interface and
RegularNonInstantiable.
What do you think?
JackDanielZ
On 01/30/2014 10:30 AM, daniel.za...@samsung.com wrote:
> 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
>
------------------------------------------------------------------------------
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
