From taking a look at the ifacemaker codebase, the current way to use types from external packages is by importing the external package into the current file's namespace using a . to instead of using package.Type. This is done by passing in the -m flag (short for --import-module=<full-package-name>) that was added in PR #52. For example:

// File: human.go
// Package full name is github.com/vburenin/ifacemaker/example/mypackage
package mypackage

import (
	"fmt"
)

type Food struct {
	name string
}

func (f *Food) Name() string {
	return f.name
}

type Human struct {
}

func (h *Human) Eat(food *Food) {
	fmt.Printf("Eating %s...\n", food.Name())
}

If you run the following command:

ifacemaker -f human.go -m "github.com/vburenin/ifacemaker/example/mypackage" -s Human -i IHuman -p otherpackage -o ihuman.go

You will get the following:

// Code generated by ifacemaker; DO NOT EDIT.

package otherpackage

import (
	. "github.com/vburenin/ifacemaker/example/mypackage"
)

// IHuman ...
type IHuman interface {
	Eat(food *Food)
}

While not documented in the README.md, this works for smaller cases like the above. A problem with this current technique though is that can lead to name conflicts if the package of the generated interface has the same name as the imported package. In this case, this PR helps deal with this issue.

When using this PR to generate the example above, we can then omit the -m flag and it will work the same way but by using the package name as a prefix to the type:

ifacemaker -f human.go -s Human -i IHuman -p otherpackage -o ihuman.go

// Code generated by ifacemaker; DO NOT EDIT.

package otherpackage

import "github.com/vburenin/ifacemaker/example/mypackage"

// IHuman ...
type IHuman interface {
	Eat(food *mypackage.Food)
}

If everything looks fine so far for the PR, I think all we need is to add a unit test for this functionality. What are your thoughts on this @gaby ? Also, this PR assumes that #65 was merged. Maybe we could merge #72 first into the master branch and merge here to ensure there are no issues between the two PR's?

@grivera64 Can you come up with a unit-test for this?