Skip to content

Merge putDtype and putType; remove duplicated code #8610

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

Noremos
Copy link
Contributor

@Noremos Noremos commented Jun 18, 2025

This is also a preparation for the JSON Type implementation

@Noremos Noremos changed the title Merge putDtype and putType, remove duplicate code Merge putDtype and putType; remove duplicated code Jun 18, 2025
Copy link
Member

@asfernandes asfernandes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you not choose better names for methods you created to not duplicate code, I prefer to have the code duplicated.
I understand nothing what the refactored methods do by their names.

putType(*type, useSubType, type->collate.object.hasData());
}

void DsqlCompilerScratch::putType(const TypeClause& type, bool useSubType, bool useExplicitCollate)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's weird that the two methods with the same name one expects the type as a pointer and the other as reference.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a design issue. A pointer means that the value can be null, and the method should check for that. But these methods explicitly treat values ​​as non_null. It would have been better to change the original putType and putDType to use references, but I avoided this to avoid changing too many files.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd make the reference-based putType() private to avoid confusion.

And maybe rename putDtype() to putFieldType() or make it a putType() overload with the dsql_fld* argument. Less than a dozen lines changed, I guess.

@Noremos
Copy link
Contributor Author

Noremos commented Jun 19, 2025

If you not choose better names for methods you created to not duplicate code, I prefer to have the code duplicated. I understand nothing what the refactored methods do by their names.

I tried to follow the style of the original method names. putType and putDtype are not the most transparent names either. So it would be nice if you could suggest alternative names for my methods

putType(*type, useSubType, type->collate.object.hasData());
}

void DsqlCompilerScratch::putType(const TypeClause& type, bool useSubType, bool useExplicitCollate)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd make the reference-based putType() private to avoid confusion.

And maybe rename putDtype() to putFieldType() or make it a putType() overload with the dsql_fld* argument. Less than a dozen lines changed, I guess.

void DsqlCompilerScratch::putType(const TypeClause* type, bool useSubType)

template<bool THasTableName>
void DsqlCompilerScratch::putTypeNameBlr(const TypeClause& type, const bool useExplicitCollate)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All put* methods are already about BLR, so it may be named just putTypeName().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the blr suffix as you suggested.

putDTypeBlr(type, useSubType);
}

void DsqlCompilerScratch::putDTypeBlr(const TypeClause& type, const bool useSubType)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIU, this method is used just once. Does it exist just to reduce the number of lines inside putType()? Anyway, it should be private, IMHO.

And if putDtype() above is renamed, then I'd suggest to remove the Blr suffix here (see the reason in the comment below).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed the putDtype to putType as you suggested

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it exist just to reduce the number of lines inside putType()

Initially, I took out only this method from putType and putDType, but then I thought that this was a half-measure and it was necessary to do a full-fledged refactoring.
For now I've left this function separate, as I hope in the future it will make it easier to refactor and use a single function to generate TypeClause and dsc blr

ERRD_bugcheck(buffer);
}
#endif
static constexpr BlrNameSet BLR_COLUMN_SET{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and below - please add the space before the curly brace or move it into a separate line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done


constexpr BlrNameSet blrSet = []()
{
if constexpr(THasTableName)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A space after constexpr, please

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

if (useExplicitCollate)
{
appendUShort(type.textType);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and above: one-liner statement bodies without braces, please.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

if constexpr (THasTableName)
differentSchema = type.typeOfTable.schema != ddlSchema;
else
differentSchema = type.typeOfName.schema != ddlSchema;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't something like this possible and maybe better?

const auto typeSchema = constexpr (THasTableName) ? type.typeOfTable.schema : type.typeOfName.schema;
if (typeSchema != ddlSchema)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if constexpr is a single construct in C++ hat discards one of the execution branches at compile time. I doubt it can be replaced.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unfortunately, there is no constexpr ternary operator. This is why I used the lambda function for the blrSet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants