This was meant to happen but did not previously happen. It is not
ideal to do it now but better do it while we still can.
In short, this removes one half of the variables API (keeps
constants as they are) and repurposes the API to be only for
constants. This is also better for consistency to match errors.
The @by_ref qualifier is now allowed on parameters, returns and
struct fields in the usual qualifier section. It will mean that
this type is passed around by reference, and will only be allowed
on types that are not already pointer-like.
The @move qualifier will replace @owned as one with a clearer
meaning. It means "transfer of ownership". It has the same semantics
as the current @owned, i.e. on return values it transfers ownership
of the value to the caller, on parameters it transfers ownership
to the callee (the inverse is the default when not specified).
On struct fields, it means the field will transfer together with
the struct that contains it.
The '@transfer' keyword is a clearer replacement for '@owned'.
It will be specified on params/returns/... to specify that
ownership will be transferred between caller/callee.
In the end this was just a failed experiment that didn't turn
out to be practical. For now, revert back to ptr(const(T)) until
a proper replacement for pointer syntax is added.
Binbuf is like strbuf and allows not using the Eina opaque wrapper
now, which will remove some ptr(). And event translates to
Efl.Event because otherwise there would be no way to get rid
of void_ptr.
You can now declare errors like this:
error Foo = "message"; [[documentation]]
Then you can use them as types like this:
foo {
return: error(Error1, Error2, ...);
}
They have a separate type category and storage. They are checked
for redefinitions the same as anything else though. This does
not add any generator support nor it adds any advanced checking.
Ref T6890
This implements initial support for specifying unit versions.
The default version is 1, specifying the basic feature level.
If you want to specify another version, you need to specify
something like `#version 2` at the beginning of the .eo or
.eot file; the version number must be higher than 0 and lower
than USHRT_MAX (typically 65536).
The beginning of the file is now called the "header section";
other things may be added into the header section later.
Version cannot be specified twice, and it cannot be specified
once other contents (like types or class definition) appear.
Comments do not count as other contents, so those are fine
to appear before #version.
@feature
@warn_unused in syntax is now called @no_unused - this is because
"warning about unused" is a C thing (or rather, an extension to C)
and various languages might want to use stricter behavior for this.
Its associated API does the reverse now - it lets you query whether
being unused is allowed at all. This is to match future behavior
of Eolian (once it supports versioning) that will likely reverse it.
@feature
This has been deprecated for a while and is not strictly necessary
- as a part of an effort to stabilize Eolian, remove this. Eolian
will eventually gain support for versioning and use a reversed
behavior (i.e. no NULL by default), but the API it wlll use for
that will be very different. Features can always be added, it's
much harder to drop them.
@feature
This was an experiment that never properly took off and was never
used by any generator. Its use was highly variable, so it could
not be relied upon. We will still want to reverse the current
behavior eventually (no null by default), but that will be
done with eo file versioning in the future.
@feature
Summary:
This removes all Eolian API that deals with handling of legacy
code. It also removes the code using it in the generator as well
as bindings, but for now keeps generation of .eo.legacy.h types,
as there are still instances in our codebase where things are
otherwise broken. We can remove the rest once that is resolved.
Reviewers: zmike, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8255
This feature was kind of ill-conceived and never worked properly.
Since there isn't enough time to make it work right at this point
and there are no users of it in the API, remove it for now.
It might get added in the next release cycle, in a proper form.
@feature
Summary:
This adds two new complex types, slice<T> and rw_slice<T>. This
is necessary to make the type useful to bindings, as Eina_Slice
on its own says nothing about what it's carrying and that prevents
useful code from being generated outside of C.
@feature
Reviewers: bu5hm4n, segfaultxavi, lauromoura, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7980
Each regular class can now have a section called 'composite',
which can contain interfaces and interfaces only. This defines
a list of interfaces that are allowed to be unimplemented on the
class, as it is assumed the class will be composited with some
other class implementing those interfaces.
Only regular classes can have this, as only regular classes can
be instantiated.
It will also be necessary to check whether the classes in the
section appear somewhere within the inheritance tree. For now,
this testing is not being done.
Example of usage:
composite {
Some.Magic.Interface;
Another.Magic.Interface;
}
directly in the class body.
This introduces a new keyword called required. It only works on mixins.
You can specify a list of regular/abstract classes in there.
Classes specified after the required keyword are later used to verify
the usage of the mixin. With this feature a mixin can define a list of
types that the inheriting object (the object that inherits from a mixin)
needs to fullfill, if one class that is required is not in the
implemented classes, then eolian will bail out.
Differential Revision: https://phab.enlightenment.org/D7584
This new syntax separates the parent class from extensions, in
a familiar way to similar to e.g. Java. Since changing everything
at once is a lot of effort, implement it alongside for the time
being.
Summary:
This tagging keyword explicitly asks, for bindings that support it,
that the constructor's parameters are added to the class constructor.
Allowing the user to instantiate the class and call the constructor in
a straightforward way.
Reviewers: q66, woohyun, bu5hm4n, Jaehyun_Cho, segfaultxavi
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers, lauromoura
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7221
This is much like 'import' but doesn't add the imported file into
the dependency list for the current file. This is to enable doc
reference validation to remain functional without needlessly
introducing file dependencies just to satisfy it.
This is a "pass by reference to const" equivalent. There is no explicit pointer
and currently it's the same as ptr(const(x)) on the type. However, it is also
usable on properties.
These types are of questionable value and the API was not entirely
thought out - remove for now, and if a legitimate use is found
later, they may be readded (with a better API), but typically it
seems best to redesign the bad APIs around safe containers...
Daniel Kolesa
Xavi Artigas
Daniel Kolesa
Marcel Hollerbach
Felipe Magno de Almeida
Cedric BAIL
Daniel Kolesa
Jean-Philippe Andre
Lauro Moura