On Mon, 22 Jun 2009 19:12:08 +0200, Roy Lyseng <Roy.Lyseng@stripped> wrote:
>
>
> Konstantin Osipov wrote:
>> * Tor Didriksen <Tor.Didriksen@stripped> [09/06/22 17:23]:
>>
>>> "Structure types are typedef'ed to an all-upper-case identifier."
>>> Can someone explain the reasoning behind this?
>>> ALL_UPPERCASE_NAME says DANGEROUS_THIS_IS_A_MACRO to me, rather than
>>> struct/class.
>>>
>>> typedef struct foo { ... } FOO;
>>> Is legacy C-style, and does not belong in a C++ style guide (imho).
>>>
>>> Roy had an email about this:
>>> http://lists.mysql.com/internals/36570
>>> I could find no objections to his mail, the thread simply died.
>>>
>>
>> This is an obsolete convention, but it is still widely used in the
>> optimizer and semantic analysis code, even in new parts of it. It
>> was difficult for me to involve some optimizer engineers into
>> discussion about the coding style.
>>
>> In runtime, I find it largely irrelevant: I advocate against
>> introduction of new struct objects into the code base, classes
>> should be used instead, and for classes we use a different naming
>> rule.
>>
>> We also have a lot of legacy code that follows this old guideline.
>> typedef's are really a pain to maintain, since they obfuscate
>> tags-jumping, make forward declarations more difficult.
>>
>> I guess updating the old code could be a task for reengineering
>> team. Drizle did it one of the first things. I would gladly review any
>> patch that removes unnecessary typedefs
>> from the code, and submit such patches myself once in a while.
>> Nobody else, however, seem to have done much about it instead of
>> talking :-<.
>>
>> Please submit a change request to the coding style group to remove
>> that rule (unless this mail is already a change request).
>>
>>
>> As Tor said, there is already a proposal:
>> http://lists.mysql.com/internals/36570.
>
> When it is accepted, I will be more than happy to start removing old
> typedefs. But I consider it a waste of time unless we have a clear rule.
>
> Thanks,
> Roy
Please note that I am not suggesting a major rewrite of existing code.
I don't think that is productive use of engineer time.
-- didrik
