Skip to content
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

Namespacing the aws funcs #148

Merged
merged 2 commits into from
Jun 9, 2017
Merged

Namespacing the aws funcs #148

merged 2 commits into from
Jun 9, 2017

Conversation

hairyhenderson
Copy link
Owner

This is an offshoot of #145 to try and figure out the best way to namespace built-in functions.

Ideally, I'd like to be able to use the existing function names, and simply move them under a namespace. So, instead of {{ ec2region }}, I'd like {{ aws.ec2region }}.

Signed-off-by: Dave Henderson dhenderson@gmail.com

@hairyhenderson
Copy link
Owner Author

The problem with this approach, as it stands right now, is that the function has to be exported to be visible, so it changes to {{ aws.EC2Region }}. I'm not a big fan of the restriction, though I'll live with it if I have to... ¯\_(ツ)_/¯

Copy link

@sean- sean- left a comment

Choose a reason for hiding this comment

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

See comments on sync.Once

aws/aws.go Outdated

// NS -
func NS() *awsFuncs {
if af == nil {
Copy link

Choose a reason for hiding this comment

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

This conditional should be replaced with a call to sync.Once or initialized in an init() function. sync.Once has the advantage of you only pay for what you use, but init() is a bit more simple to grok and idiomatic.

Copy link
Owner Author

Choose a reason for hiding this comment

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

thanks, this seemed inelegant, but I didn't want to use init() - I'll replace with sync.Once 🙂

aws/aws.go Outdated
type awsFuncs struct{}

func (a *awsFuncs) EC2Region(def ...string) string {
if meta == nil {
Copy link

Choose a reason for hiding this comment

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

Ditto this conditional.

@hairyhenderson hairyhenderson force-pushed the aws-namespace branch 3 times, most recently from 877836c to 9ce9d1e Compare May 30, 2017 03:29
@hairyhenderson
Copy link
Owner Author

I've been doing some digging around the upper/lower-case function name problem, and I found some discussion of how they did it in hugo - gohugoio/hugo#3042

It looks like basically the same approach was tried initially but in the end they seem to have gone with something more complex. I'm still wrapping my head around what exactly was done - most of the magic seems to be in https://github.com/spf13/hugo/tree/master/tpl

@hairyhenderson
Copy link
Owner Author

Ok, seems I totally misunderstood what's going on in hugo - they don't seem to support lower-cased function names in namespaces. What I was looking at was aliases, which are in the global namespace.

We're stuck with upper-cased function names. NBD. I'll move on with life now 😛

@hairyhenderson hairyhenderson force-pushed the aws-namespace branch 2 times, most recently from 3a356d2 to 9556e07 Compare June 6, 2017 01:04
@hairyhenderson
Copy link
Owner Author

I think this is ready to go... I've split out the docs to reflect the namespacing, and I'm not super happy with the way the docs flow, but it'll have to do for now!

@sean- @jen20 - I think this approach will work for #145 - WDYT?

@hairyhenderson hairyhenderson changed the title [WIP] Namespacing the aws funcs Namespacing the aws funcs Jun 6, 2017
@hairyhenderson hairyhenderson force-pushed the aws-namespace branch 3 times, most recently from e2ad280 to 8c6440d Compare June 9, 2017 00:35
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
@hairyhenderson hairyhenderson merged commit cac0bc6 into master Jun 9, 2017
@hairyhenderson hairyhenderson deleted the aws-namespace branch June 9, 2017 00:48
@sean-
Copy link

sean- commented Jun 11, 2017

@hairyhenderson Are you good with this approach now?

@hairyhenderson
Copy link
Owner Author

@sean- yeah, it seems to be fine. There's probably further refinements that could be made to the specifics, but as a general approach I'm happy with it for now.

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.

2 participants