Skip to content

deduplicate the 'isSomeFunction' equivalent#6835

Closed
UplinkCoder wants to merge 1 commit intodlang:masterfrom
UplinkCoder:function_traits
Closed

deduplicate the 'isSomeFunction' equivalent#6835
UplinkCoder wants to merge 1 commit intodlang:masterfrom
UplinkCoder:function_traits

Conversation

@UplinkCoder
Copy link
Member

Since the code is now used multiple times in __traits let's dedup it.

return new IntegerExp(e.loc, false, Type.tbool);
}

TypeFunction firstArgFunctionType()
Copy link
Member

Choose a reason for hiding this comment

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

IMO a better abstraction is toTypeFunction(RootObject o) and passing the validated parameter into this function. That would allow it not being a nested function and used elsewhere, too.

Even better, I'd split it into two overloads, one for Type, and one for Dsymbol, as you now have widen the allowed parameters to traits that support types only so far.

Copy link
Member Author

Choose a reason for hiding this comment

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

the reason I did not do this is because I'd have to import rootobject

Copy link
Member Author

Choose a reason for hiding this comment

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

also let's generalize when/if needed and not on speculation.

Copy link
Member Author

Choose a reason for hiding this comment

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

@rainers do you agree ?

Copy link
Member

Choose a reason for hiding this comment

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

do you agree ?

Mostly. The diff didn't show that there's also support for function symbols in the other traits.

You should remove the handling for FuncDeclaration in traits getLinkage, getFunctionVariadicStyle and getParameterStorageClasses, though. It is duplicated now.

the reason I did not do this is because I'd have to import rootobject

That's not really a good excuse. You can also use typeof(args[0]) to avoid an import... ;-)

@UplinkCoder
Copy link
Member Author

travis fails because of connection error

@wilzbach
Copy link
Contributor

@UplinkCoder UplinkCoder force-pushed the function_traits branch 2 times, most recently from 722b1f9 to 58d5861 Compare May 27, 2017 19:04
@UplinkCoder
Copy link
Member Author

@rainers do you like it better now ?

@UplinkCoder
Copy link
Member Author

@WalterBright any objections ?

return new IntegerExp(e.loc, false, Type.tbool);
}

static TypeFunction traitsFuncArg(RootObject o, FuncDeclaration* fdp = null)
Copy link
Member

Choose a reason for hiding this comment

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

No documentation saying what function does.

@WalterBright
Copy link
Member

LGTM provided the function is documented

@WalterBright
Copy link
Member

use typeof(args[0]) to avoid an import... ;-)

Not a bad idea.

@UplinkCoder UplinkCoder force-pushed the function_traits branch 3 times, most recently from 41897b0 to 3b8ef98 Compare May 28, 2017 11:38
In case of a function declaration being passed verbatim
it will set the second optional argument to the FuncDeclarartion
given it was provided.
*/
Copy link
Member

Choose a reason for hiding this comment

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

Please use Ddoc style documentation. It this case it means having a Params: section and a Returns: section. This is the standard for new functions.

Copy link
Contributor

Choose a reason for hiding this comment

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

@UplinkCoder don't forget that we already publish the documentation of ddmd on dlang.org:

This is also why it can be very helpful for both the contributor and the reviewers to preview the style changes at Vladimir's excellent DAutoTest, e.g.

http://dtest.dlang.io/artifact/website-72ba79b73f635fb08bdfe69d6826833c1c4c2ee0-6f020744a26d63533038dc39e44ae752/web/library-prerelease/ddmd/traits.html

(in this case it's a function within a function and thus not publicly accessible)


/**
if traitsFuncArg is passed either a delegate. a function
or a function pointer or a variable of types.
Copy link
Member

Choose a reason for hiding this comment

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

omit trailing period in middle of sentence

it will return the functionType.
else it will return null

In case of a function declaration being passed verbatim
Copy link
Member

Choose a reason for hiding this comment

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

passed verbatim has no meaning in regards to code.

Returns: a function-type if
o is a declarion of type delegate, function,
or function pointer
or a variable of those types.
Copy link
Member

Choose a reason for hiding this comment

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

When using periods, please do not put them in the middle of sentences. Replace it with a ,

Copy link
Member Author

Choose a reason for hiding this comment

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

@WalterBright do you like it better now ?

@UplinkCoder
Copy link
Member Author

@WalterBright addressed.

}

/**
Params: o: the AST-node to check.
Copy link
Member

Choose a reason for hiding this comment

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

Please read the Ddoc documentation I provided a link for. Note the o: in the above line. This is not how it's done and Ddoc will not work with it. It's o=.

@JinShil
Copy link
Contributor

JinShil commented Dec 19, 2017

@UplinkCoder Are you going to take this across the finish line?


/**
Params: o: the AST-node to check.
Params: fdp: optionally a pointer to a function declararion,
Copy link
Contributor

Choose a reason for hiding this comment

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

declararion --> declaration

else
it will return null.
*/
static TypeFunction traitsFuncArg(RootObject o, FuncDeclaration* fdp = null)
Copy link
Contributor

Choose a reason for hiding this comment

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

I recommend a different name. Perhaps getTypeFunction.

it will return the functionType
else
it will return null.
*/
Copy link
Contributor

Choose a reason for hiding this comment

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

I offer you this documentation header:

/**
 Gets the `TypeFunction` for `o`
 Params:
    o   = the AST node to get the `TypeFunction` for
    fdp = optional pointer to a function declararion, to be set 
          if `o` is a function declarartion
 Returns: 
    a `TypeFunction` if `o` is a declaration for a delegate, function,
    or avariable of those types.  Otherwise, `null`
*/

Choose a reason for hiding this comment

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

Neat Thanks!

@andralex
Copy link
Member

@UplinkCoder ping?

@dlang-bot
Copy link
Contributor

Thanks for your pull request, @UplinkCoder!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

or a variable of the former. Otherwise, `null`.
*/

static TypeFunction traitsFuncArg(RootObject o, FuncDeclaration* fdp = null)
Copy link
Contributor

Choose a reason for hiding this comment

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

All other DDoc headers in DMD seem to follow this convention:

/*************************************************************
 * Whatever
 * Whatever
 */

Please remove the extra space between the DDoc header and the function declaration.

I cannot, in good conscience, approve a function name like traitsFuncArg. Please use a more descriptive name like getFuncType or something along those lines (Yes, I know my own names have been poor).

Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove the extra space between the DDoc header and the function declaration.

Hmm the above is the Phobos style:
Compare with e.g. https://github.com/dlang/phobos/blob/master/std/algorithm/comparison.d

If you really want to stick with this style at DMD, then this should be documented in a DMD-specific style guide?

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm the above is the Phobos style.

I see.

If you really want to stick with this style at DMD, then this should be documented in a DMD-specific style guide.

Agreed.

Aside from the name then, LGTM.

Copy link
Contributor

@JinShil JinShil Dec 21, 2017

Choose a reason for hiding this comment

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

Also, consider making this a non-member function instead of static, and preferably private. Refer to @WalterBright's comment

Copy link
Contributor

@jacob-carlborg jacob-carlborg Dec 21, 2017

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

@JinShil JinShil added the Review:Phantom Zone Has value/information for future work, but closed for now label Jan 17, 2018
@JinShil
Copy link
Contributor

JinShil commented Jan 17, 2018

This PR needs to have the reviewers' concerns addressed and rebased.

This PR is nice, and normally I would revive such a PR if the author was no longer active. I would also revive it if it were an important bug fix or something of higher priority. This PR, however, is just a refactoring, so I'm going to put it in the Phantom Zone and close it for now.

@JinShil JinShil closed this Jan 17, 2018
@JinShil JinShil added the Severity:Refactoring No semantic changes to code label Jan 17, 2018
@JinShil
Copy link
Contributor

JinShil commented Jan 18, 2018

Resubmitted at #7749

@JinShil JinShil removed the Review:Phantom Zone Has value/information for future work, but closed for now label Jan 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants