You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Yuxuan Wang <yu...@reddit.com.INVALID> on 2022/09/09 17:24:54 UTC
The UUID change seems to be a big breaking change
I was trying the compiler from the latest master branch, and got this error
on one of our existing thrift files:
[ERROR:/path/to/file.thrift:182] (last token was 'uuid')
The line is basically a field named uuid:
40: optional string uuid,
So I think what happens is that uuid is now a reserved word of thrift, and
we can no longer use it as the name of a field/struct/etc. (the same as we
cannot name a field "string" or "i64")
This is a big problem. This means that old thrift file no longer compiles
without modification (uuid is likely a commonly used field name right now
when we actually needs an uuid there), and renaming an existing field is
also a breaking change (it means all the code have to be changed to
accommodate the new field name).
I'm not sure how feasible it is to make it not a reserved word?
Re: The UUID change seems to be a big breaking change
Posted by Jens Geyer <je...@hotmail.com>.
> I’m not sure how to it works with Flex & Bison
Yes. If it would not, its the wrong tool.
See also https://issues.apache.org/jira/browse/THRIFT-5626 I'm on it
already.
Am 10.09.2022 um 11:16 schrieb Triton Circonflexe:
> I’m not sure how to it works with Flex & Bison but there should be a way to
> indicate that if the word in context should not be a specific token (in
> this case, it’s not reserved), then the parser should fallback to interpret
> it as something else (in this case, an identifier).
>
> At the moment, every simple type name (i8…i64, binary, …) is considered to
> be a reserved word even if the specification does not list them as such.
>
> Le ven. 9 sept. 2022 à 23:27, Jens Geyer <je...@hotmail.com> a écrit :
>
>> I would say that the parser is broken then. Why should I not be able to
>> call my field "uuid"?
>>
>>
>> Am 09.09.2022 um 21:41 schrieb Duru Can Celasun:
>>> Agreed. It seems a new reserved word is unavoidable, so let's at least
>> prefix it.
>>> On Fri, 9 Sep 2022, at 18:30, Yuxuan Wang wrote:
>>>> If making it not a reserved word is infeasible, my next suggestion
>> would be
>>>> to rename it to something like "tuuid" (similar to how we prefix t to a
>> lot
>>>> of the names).
>>>>
>>>> It would still be a big breaking change if someone have a thrift file
>> with
>>>> a field/type named tuuid, but that's far less likely compare to the name
>>>> uuid.
>>>>
>>>> On Fri, Sep 9, 2022 at 10:24 AM Yuxuan Wang <yu...@reddit.com>
>> wrote:
>>>>> I was trying the compiler from the latest master branch, and got this
>>>>> error on one of our existing thrift files:
>>>>>
>>>>> [ERROR:/path/to/file.thrift:182] (last token was 'uuid')
>>>>>
>>>>> The line is basically a field named uuid:
>>>>>
>>>>> 40: optional string uuid,
>>>>>
>>>>> So I think what happens is that uuid is now a reserved word of thrift,
>> and
>>>>> we can no longer use it as the name of a field/struct/etc. (the same
>> as we
>>>>> cannot name a field "string" or "i64")
>>>>>
>>>>> This is a big problem. This means that old thrift file no longer
>> compiles
>>>>> without modification (uuid is likely a commonly used field name right
>> now
>>>>> when we actually needs an uuid there), and renaming an existing field
>> is
>>>>> also a breaking change (it means all the code have to be changed to
>>>>> accommodate the new field name).
>>>>>
>>>>> I'm not sure how feasible it is to make it not a reserved word?
>>>>>
>
Re: The UUID change seems to be a big breaking change
Posted by Triton Circonflexe <tr...@kumal.info>.
I’m not sure how to it works with Flex & Bison but there should be a way to
indicate that if the word in context should not be a specific token (in
this case, it’s not reserved), then the parser should fallback to interpret
it as something else (in this case, an identifier).
At the moment, every simple type name (i8…i64, binary, …) is considered to
be a reserved word even if the specification does not list them as such.
Le ven. 9 sept. 2022 à 23:27, Jens Geyer <je...@hotmail.com> a écrit :
>
> I would say that the parser is broken then. Why should I not be able to
> call my field "uuid"?
>
>
> Am 09.09.2022 um 21:41 schrieb Duru Can Celasun:
> > Agreed. It seems a new reserved word is unavoidable, so let's at least
> prefix it.
> >
> > On Fri, 9 Sep 2022, at 18:30, Yuxuan Wang wrote:
> >> If making it not a reserved word is infeasible, my next suggestion
> would be
> >> to rename it to something like "tuuid" (similar to how we prefix t to a
> lot
> >> of the names).
> >>
> >> It would still be a big breaking change if someone have a thrift file
> with
> >> a field/type named tuuid, but that's far less likely compare to the name
> >> uuid.
> >>
> >> On Fri, Sep 9, 2022 at 10:24 AM Yuxuan Wang <yu...@reddit.com>
> wrote:
> >>
> >>> I was trying the compiler from the latest master branch, and got this
> >>> error on one of our existing thrift files:
> >>>
> >>> [ERROR:/path/to/file.thrift:182] (last token was 'uuid')
> >>>
> >>> The line is basically a field named uuid:
> >>>
> >>> 40: optional string uuid,
> >>>
> >>> So I think what happens is that uuid is now a reserved word of thrift,
> and
> >>> we can no longer use it as the name of a field/struct/etc. (the same
> as we
> >>> cannot name a field "string" or "i64")
> >>>
> >>> This is a big problem. This means that old thrift file no longer
> compiles
> >>> without modification (uuid is likely a commonly used field name right
> now
> >>> when we actually needs an uuid there), and renaming an existing field
> is
> >>> also a breaking change (it means all the code have to be changed to
> >>> accommodate the new field name).
> >>>
> >>> I'm not sure how feasible it is to make it not a reserved word?
> >>>
>
--
Triton.
Re: The UUID change seems to be a big breaking change
Posted by Jens Geyer <je...@hotmail.com>.
I would say that the parser is broken then. Why should I not be able to
call my field "uuid"?
Am 09.09.2022 um 21:41 schrieb Duru Can Celasun:
> Agreed. It seems a new reserved word is unavoidable, so let's at least prefix it.
>
> On Fri, 9 Sep 2022, at 18:30, Yuxuan Wang wrote:
>> If making it not a reserved word is infeasible, my next suggestion would be
>> to rename it to something like "tuuid" (similar to how we prefix t to a lot
>> of the names).
>>
>> It would still be a big breaking change if someone have a thrift file with
>> a field/type named tuuid, but that's far less likely compare to the name
>> uuid.
>>
>> On Fri, Sep 9, 2022 at 10:24 AM Yuxuan Wang <yu...@reddit.com> wrote:
>>
>>> I was trying the compiler from the latest master branch, and got this
>>> error on one of our existing thrift files:
>>>
>>> [ERROR:/path/to/file.thrift:182] (last token was 'uuid')
>>>
>>> The line is basically a field named uuid:
>>>
>>> 40: optional string uuid,
>>>
>>> So I think what happens is that uuid is now a reserved word of thrift, and
>>> we can no longer use it as the name of a field/struct/etc. (the same as we
>>> cannot name a field "string" or "i64")
>>>
>>> This is a big problem. This means that old thrift file no longer compiles
>>> without modification (uuid is likely a commonly used field name right now
>>> when we actually needs an uuid there), and renaming an existing field is
>>> also a breaking change (it means all the code have to be changed to
>>> accommodate the new field name).
>>>
>>> I'm not sure how feasible it is to make it not a reserved word?
>>>
Re: The UUID change seems to be a big breaking change
Posted by Duru Can Celasun <dc...@apache.org>.
Agreed. It seems a new reserved word is unavoidable, so let's at least prefix it.
On Fri, 9 Sep 2022, at 18:30, Yuxuan Wang wrote:
> If making it not a reserved word is infeasible, my next suggestion would be
> to rename it to something like "tuuid" (similar to how we prefix t to a lot
> of the names).
>
> It would still be a big breaking change if someone have a thrift file with
> a field/type named tuuid, but that's far less likely compare to the name
> uuid.
>
> On Fri, Sep 9, 2022 at 10:24 AM Yuxuan Wang <yu...@reddit.com> wrote:
>
>> I was trying the compiler from the latest master branch, and got this
>> error on one of our existing thrift files:
>>
>> [ERROR:/path/to/file.thrift:182] (last token was 'uuid')
>>
>> The line is basically a field named uuid:
>>
>> 40: optional string uuid,
>>
>> So I think what happens is that uuid is now a reserved word of thrift, and
>> we can no longer use it as the name of a field/struct/etc. (the same as we
>> cannot name a field "string" or "i64")
>>
>> This is a big problem. This means that old thrift file no longer compiles
>> without modification (uuid is likely a commonly used field name right now
>> when we actually needs an uuid there), and renaming an existing field is
>> also a breaking change (it means all the code have to be changed to
>> accommodate the new field name).
>>
>> I'm not sure how feasible it is to make it not a reserved word?
>>
Re: The UUID change seems to be a big breaking change
Posted by Yuxuan Wang <yu...@reddit.com.INVALID>.
If making it not a reserved word is infeasible, my next suggestion would be
to rename it to something like "tuuid" (similar to how we prefix t to a lot
of the names).
It would still be a big breaking change if someone have a thrift file with
a field/type named tuuid, but that's far less likely compare to the name
uuid.
On Fri, Sep 9, 2022 at 10:24 AM Yuxuan Wang <yu...@reddit.com> wrote:
> I was trying the compiler from the latest master branch, and got this
> error on one of our existing thrift files:
>
> [ERROR:/path/to/file.thrift:182] (last token was 'uuid')
>
> The line is basically a field named uuid:
>
> 40: optional string uuid,
>
> So I think what happens is that uuid is now a reserved word of thrift, and
> we can no longer use it as the name of a field/struct/etc. (the same as we
> cannot name a field "string" or "i64")
>
> This is a big problem. This means that old thrift file no longer compiles
> without modification (uuid is likely a commonly used field name right now
> when we actually needs an uuid there), and renaming an existing field is
> also a breaking change (it means all the code have to be changed to
> accommodate the new field name).
>
> I'm not sure how feasible it is to make it not a reserved word?
>