On 15 October 2015 at 09:18, Erik De Rijcke wrote:
> If wayland enums would not explicitly declare values, you'd have the same
> problem in C. However since wayland enums do explicitly declare their value,
> *and* because C allows you to override an enum 'internal value', you don't
> have that pro
Hi,
On 15 October 2015 at 09:18, Erik De Rijcke wrote:
> On Tue, Oct 13, 2015 at 9:27 PM, Auke Booij wrote:
>> New values may be added (but not
>> changed or removed) to protocol specifications without introducing any
>> compatibility issues.
>
> This is not clear for me. Compatibility issues fo
On Tue, Oct 13, 2015 at 9:27 PM, Auke Booij wrote:
>
> I really don't understand this discussion. Is the claim that the usage
> of enums in java is problematic, because inserting a new value in an
> existing enum might change the index of later values, thereby creating
> an inconsistency?
>
Corre
Hi,
On Wed, Oct 14, 2015 at 10:25 AM, Pekka Paalanen wrote:
> On Tue, 13 Oct 2015 20:27:58 +0100
> Auke Booij wrote:
>
>> On 13 October 2015 at 16:19, Solerman Kaplon wrote:
>> > Em 13-10-2015 11:35, Nils Chr. Brause escreveu:
>> >>
>> >> In C++ the order doesn't matter either, since each entry
On Tue, 13 Oct 2015 20:27:58 +0100
Auke Booij wrote:
> On 13 October 2015 at 16:19, Solerman Kaplon wrote:
> > Em 13-10-2015 11:35, Nils Chr. Brause escreveu:
> >>
> >> In C++ the order doesn't matter either, since each entry has a defined
> >> value. I wonder why this is different in Java?
> I
On Tue, 13 Oct 2015 10:19:43 -0700
Bill Spitzak wrote:
> On 10/13/2015 08:18 AM, Erik De Rijcke wrote:
>
> > Because Java is not C/C++. In Java, enum values are unique by instance
> > alone. It does not have user 'defined' value(s) that make it unique. It
> > *can* have user defined properties (
On Tue, Oct 13, 2015 at 08:27:58PM +0100, Auke Booij wrote:
> On 13 October 2015 at 16:19, Solerman Kaplon wrote:
> > Em 13-10-2015 11:35, Nils Chr. Brause escreveu:
> >>
> >> In C++ the order doesn't matter either, since each entry has a defined
> >> value. I wonder why this is different in Java?
On 13 October 2015 at 16:19, Solerman Kaplon wrote:
> Em 13-10-2015 11:35, Nils Chr. Brause escreveu:
>>
>> In C++ the order doesn't matter either, since each entry has a defined
>> value. I wonder why this is different in Java?
>
>
> Java Enums doesn't have "value". It just a class instance. But
On 10/13/2015 08:18 AM, Erik De Rijcke wrote:
Because Java is not C/C++. In Java, enum values are unique by instance
alone. It does not have user 'defined' value(s) that make it unique. It
*can* have user defined properties (like any object) in addition to
implicit compiler generated enum type
On Tue, Oct 13, 2015 at 5:18 PM, Erik De Rijcke wrote:
>
>
> On Tue, Oct 13, 2015 at 4:35 PM, Nils Chr. Brause
> wrote:
>>
>> Hi,
>>
>> On Mon, Oct 12, 2015 at 11:08 AM, Pekka Paalanen
>> wrote:
>> > On Mon, 12 Oct 2015 10:41:22 +0200
>> > Erik De Rijcke wrote:
>> >
>> >> Adding enum members is
Em 13-10-2015 11:35, Nils Chr. Brause escreveu:
In C++ the order doesn't matter either, since each entry has a defined value.
I wonder why this is different in Java?
Java Enums doesn't have "value". It just a class instance. But since it's a
class one can add regular fields to it, like this (w
On Tue, Oct 13, 2015 at 4:35 PM, Nils Chr. Brause
wrote:
> Hi,
>
> On Mon, Oct 12, 2015 at 11:08 AM, Pekka Paalanen
> wrote:
> > On Mon, 12 Oct 2015 10:41:22 +0200
> > Erik De Rijcke wrote:
> >
> >> Adding enum members is backward compatible for Java. If you compile
> against
> >> an enum with
Hi,
On Mon, Oct 12, 2015 at 11:08 AM, Pekka Paalanen wrote:
> On Mon, 12 Oct 2015 10:41:22 +0200
> Erik De Rijcke wrote:
>
>> Adding enum members is backward compatible for Java. If you compile against
>> an enum with 2 members, and later on a new member is added, you can simply
>> use the new v
On Mon, 12 Oct 2015 10:41:22 +0200
Erik De Rijcke wrote:
> Adding enum members is backward compatible for Java. If you compile against
> an enum with 2 members, and later on a new member is added, you can simply
> use the new version of the enum.
>
> Important however is that the order of old me
Adding enum members is backward compatible for Java. If you compile against
an enum with 2 members, and later on a new member is added, you can simply
use the new version of the enum.
Important however is that the order of old members do not change when new
members are added.
On Thu, Oct 8, 2015
Hi,
On Thu, Oct 8, 2015 at 10:13 PM, Daniel Stone wrote:
> Hi,
>
> On 5 October 2015 at 21:31, Victor Berger wrote:
>> Le 2015-10-05 21:53, Nils Chr. Brause a écrit :
>>> Since a language binding should support unknown values anyway, I don't
>>> quite
>>> see the benefit of an 'open' flag.
>>
>>
Hi,
On 8 October 2015 at 21:13, Daniel Stone wrote:
> On 5 October 2015 at 21:31, Victor Berger wrote:
>> In this case, for a "closed" enum, the binding can decide to ignore any
>> value received on the wire that is not described in the XML, as anyway, the
>> client would not know what to do wit
Hi,
On 5 October 2015 at 21:31, Victor Berger wrote:
> Le 2015-10-05 21:53, Nils Chr. Brause a écrit :
>> Since a language binding should support unknown values anyway, I don't
>> quite
>> see the benefit of an 'open' flag.
>
> It depends. In some case, it could be valid to support unknown values
I see. You're right. :)
On 5 Oct 2015 22:31, "Victor Berger" wrote:
>
> Le 2015-10-05 21:53, Nils Chr. Brause a écrit :
>>
>> Bill Spitzak wrote:
>>>
>>> Similarly it seems like an "open" indicator that can be added to enums
>>> (including bitfields) would help, as it sounds like some languages m
Le 2015-10-05 21:53, Nils Chr. Brause a écrit :
Bill Spitzak wrote:
Similarly it seems like an "open" indicator that can be added to enums
(including bitfields) would help, as it sounds like some languages
make it
difficult or cryptic to allow casting of arbitrary numbers to the enum
value.
Th
Hi,
Auke Booij wrote:
> I think that we have an agreement in principle, just not in terms (and
> this also goes back to my comment to Victor Berger). What I meant to
> express is that any bindings that violate this rule are on the risk of
> the bindings writers, rather than the wayland and wayland
On Mon, Oct 5, 2015 at 6:03 AM, Pekka Paalanen wrote:
> For me, that depends only on what requirements a "bitfield" has. Does
> it have to be uint? Do the values have to be POT? That's all up to you,
> as it has no effect on C bindings nor generated documentation other
> than wording.
>
>
I beli
Re-adding the CCs: Jeroen, Jason, Boyan.
Jeroen is the one who started the April 2015 thread on this.
On Sun, 4 Oct 2015 22:15:12 +0100
Auke Booij wrote:
> This email contains a clear suggestions that I'd like everyone to
> read, not just Nils and Erik. But Nils and Erik brought up a few
> poin
On Sat, 3 Oct 2015 12:14:19 +0200
"Nils Chr. Brause" wrote:
> Pekka Paalanen wrote:
> > We could have a "strict mode" to wayland-scanner, where you need to
> > feed all relevant additional XML files also, and the check would be
> > cross-file then, erroring on all unknown links. Then we'd just ch
This email contains a clear suggestions that I'd like everyone to
read, not just Nils and Erik. But Nils and Erik brought up a few
points that I'd like to have settled, since they have been brought up
quite frequently now.
On 3 October 2015 at 11:14, Nils Chr. Brause wrote:
> Pekka Paalanen wrote
Hi,
On Sat, Oct 3, 2015 at 9:05 PM, Erik De Rijcke wrote:
> - Defining an uint (bitfield) or int (single enum) in the xml for an enum
> argument is the wrong approach. It prescribes, not describes. In some
> languages eg Java, there is no such thing as an uint. What is important, is
> to know how
The enum discussion seems to become a lengthy one and it's becoming hard to
see the forest for the trees.
I'll give my input as a Java bindings dev. Please correct any bad
assumptions or observations I've made.
>From what I see in Auke's patches:
- Defining an uint (bitfield) or int (single enum
Hi,
Pekka Paalanen wrote:
> Adding these attributes to XML must not change the signatures generated
> by wayland-scanner.
>
> Why: these are also used in C++, which does not implicitly covert
> between enums and other stuff, which would break the build.
> http://lists.freedesktop.org/archives/wayl
On Fri, Oct 02, 2015 at 03:48:33PM +0300, Pekka Paalanen wrote:
> On Fri, 2 Oct 2015 12:53:13 +0100
> Auke Booij wrote:
>
> > On 1 October 2015 at 20:00, Nils Chr. Brause
> > wrote:
>
> > > I would prefer, if the enum attributes would also name the interface,
> > > where the enum can be found,
On 2 October 2015 at 14:49, Victor Berger wrote:
> Le 2015-10-02 15:16, Pekka Paalanen a écrit :
>>
>> On Fri, 2 Oct 2015 13:50:42 +0100
>> Auke Booij wrote:
>>>
>>>
>>> [start]
>>> The enum and bitfield attributes are in principle for documentation
>>> purposes only. The enum and bitfield attrib
On Fri, 02 Oct 2015 15:49:15 +0200
Victor Berger wrote:
> Le 2015-10-02 15:16, Pekka Paalanen a écrit :
> > On Fri, 2 Oct 2015 13:50:42 +0100
> > Auke Booij wrote:
> >>
> >> [start]
> >> The enum and bitfield attributes are in principle for documentation
> >> purposes only. The enum and bitfiel
Le 2015-10-02 15:16, Pekka Paalanen a écrit :
On Fri, 2 Oct 2015 13:50:42 +0100
Auke Booij wrote:
[start]
The enum and bitfield attributes are in principle for documentation
purposes only. The enum and bitfield attributes may also be used by
bindings, but only in such a way that code written p
On Fri, 2 Oct 2015 13:50:42 +0100
Auke Booij wrote:
> Maybe a solution can be found in more languages, and we can make the
> compatibility, that e.g. Pekka is looking for, a requirement for
> bindings, rather than make compatibility a requirement for the
> protocol writers. So something along the
On Fri, 02 Oct 2015 14:43:57 +0200
Victor Berger wrote:
> Le 2015-10-02 14:12, Auke Booij a écrit :
> > However, I'm not sure who you are trying to protect here. Everyone
> > agrees that the new attributes should not change anything for C/C++,
> > and in the current patches, they don't. And the o
Le 2015-10-02 14:12, Auke Booij a écrit :
However, I'm not sure who you are trying to protect here. Everyone
agrees that the new attributes should not change anything for C/C++,
and in the current patches, they don't. And the other bindings writers
understand the compatibility issues regarding th
On 2 October 2015 at 13:12, Auke Booij wrote:
> The wayland protocol currently does not specify the enum attribute,
> and I see no way how to write an API whose entire purpose is to
> *break* when you erroneously mix up enum attribute data, without
> breaking API as this data is added.
Actually,
On Fri, 2 Oct 2015 12:53:13 +0100
Auke Booij wrote:
> On 1 October 2015 at 20:00, Nils Chr. Brause wrote:
> > I would prefer, if the enum attributes would also name the interface,
> > where the enum can be found, e.g.:
> >
> > If two enums in different interfaces happen to have the same na
On 2 October 2015 at 12:31, Pekka Paalanen wrote:
>> I know that several people have proposed patches on this - Bill, Nils
>> and Auke at least. Since there's a definite need for this, and since
>> agreement appears to be not far off, I would like to get this landed
>> this release. And ideally
On 1 October 2015 at 20:00, Nils Chr. Brause wrote:
>> Since Auke's patchset proposalis the most recent, let's take that one as
>> the candidate for landing. Gentlemen, I'd like to ask you to review
>> these three patches [5,6,7] and either give your Reviewed-by's or flag
>> specific improvements
Thanks for bringing this up again, Bryce.
On 1 October 2015 at 18:59, Jasper St. Pierre wrote:
> We have a few constraints. First off, not all enums are closed. Some
> are intentionally open, like xdg_shell.state. So we definitely need a
> distinction between a closed enum and an open enum. I'm n
Hi all,
let's add Jeroen, Jason, Boyan to CC.
The fundamental requirement here is that we must not break existing
code or users. All arguments I have can be traced back to this simple
statement.
First, I would rather keep the wl_array discussion in a separate thread
and not mix it up here. What
On Fri, 25 Sep 2015 12:43:55 +0200
Victor Berger wrote:
> On 2015-09-25 12:25, Nils Chr. Brause wrote :
> > Hi,
> >
> > On Fri, Sep 25, 2015 at 10:52 AM, Victor Berger
> > wrote:
> >> The questions about how breaking evolutions will be handled need to be
> >> specified as well: how should an o
On Fri, 25 Sep 2015 12:25:51 +0200
"Nils Chr. Brause" wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 10:52 AM, Victor Berger
> wrote:
> >
> > What I meant here is that the format and contents of the XML files is
> > currently defined by the implementation of the C scanner, which is a less
> > than op
On Thu, Oct 1, 2015 at 12:00 PM, Nils Chr. Brause
wrote:
>
> There are some enum attributes missing, namely:
> - wl_shm_pool::create_buffer::format (it's wl_shm::format)
> - wl_shell_surface::set_fullscreen::method (it's
> wl_shell_surface::fullscreen_method)
> - wl_surface::set_buffer_transform:
Hi,
On Thu, Oct 1, 2015 at 7:49 PM, Bryce Harrington wrote:
> The topic of adding better enum/bitfield support to the protocol has
> come up a few[0] times[1] in the past, and again more recently[2]. We
> also have several proposed patches in patchwork, but I'm not sure they
> reflect consensus
I'm not sure why one of the large patches seems to be attributed to me, it
is actually Auke's.
My only contribution was a small patch (number 4) to use the enum/bitfield
information in the generated docs. My patch is slightly different that
Auke's proposal and he liked it better, I was just holdin
We have a few constraints. First off, not all enums are closed. Some
are intentionally open, like xdg_shell.state. So we definitely need a
distinction between a closed enum and an open enum. I'm not familiar
enough with Rust to be able to apply something to that.
Second, I think we need to make a
The topic of adding better enum/bitfield support to the protocol has
come up a few[0] times[1] in the past, and again more recently[2]. We
also have several proposed patches in patchwork, but I'm not sure they
reflect consensus and none have Reviewed-by's on them yet [3,4,5,6,7].
From what I gath
On 2015-09-25 12:25, Nils Chr. Brause wrote :
Hi,
On Fri, Sep 25, 2015 at 10:52 AM, Victor Berger
wrote:
What I meant here is that the format and contents of the XML files is
currently defined by the implementation of the C scanner, which is a
less
than optimal situation to discuss evolutio
Hi,
On Fri, Sep 25, 2015 at 10:52 AM, Victor Berger
wrote:
>
> What I meant here is that the format and contents of the XML files is
> currently defined by the implementation of the C scanner, which is a less
> than optimal situation to discuss evolutions of this format.
>
> There will most likel
Hi,
First of all, thanks for your replies.
On 2015-09-24 20:35, Bill Spitzak wrote :
Um, that is entirely the point of this change! The current xml does
not provide enough information so that a language binding can know
that some arrangements are illegal. Therefore current language
bindings do
On Thu, Sep 24, 2015 at 4:00 AM, Victor Berger <
victor.ber...@polytechnique.org> wrote:
> Hi,
>
> After some discussions on IRC, it appears this raises several concerns
> about back-compatibility.
>
> The main points being:
>
> - if a protocol file previously did not use these extra attributes, a
Hi
These are all very interesting points.
I understand that some language bindings might break existing code, if
they want to use the 'enum' and 'bitfield' attributes. But they could
simply bump the major version of their bindings, in that case. In my
opinion this is a low price to pay for highe
Hi,
After some discussions on IRC, it appears this raises several concerns
about back-compatibility.
The main points being:
- if a protocol file previously did not use these extra attributes, and
choses to add them, depending on the language using them it can be a
breaking change (as it wou
On Fri, Sep 18, 2015 at 5:37 AM, Nils Chr. Brause
wrote:
> Hi,
>
> There are even earlier discussions about including 'bitfield' and
> 'enum' fields into the XML protocol file, e.g:
>
> http://lists.freedesktop.org/archives/wayland-devel/2014-September/017071.html
> But none of them led to any ac
Hi,
There are even earlier discussions about including 'bitfield' and
'enum' fields into the XML protocol file, e.g:
http://lists.freedesktop.org/archives/wayland-devel/2014-September/017071.html
But none of them led to any actual changes.
I still would very much like to see the 'bitfield' and 'e
Hi,
I would like to revive a previous discussion that apparently died a few
months ago on this mailing-list: the question of adding information
specifying when a (u)int argument in a message is supposed to be a value
of an enum, and which is the associated enum, as well a specifying when
an e
57 matches
Mail list logo
