Enum: fixed #4269, work fine with private

[makenowjust]

Fixed #4269.

Use new({{@type.constant member}}) instead of {{@type}}::{{member}}. It works fine. However I think, Enum.flags macro cannot implement correctly on current Crystal compiler.

[bcardiff]

The expanded code is not that nice since it use the values of the enum instead of their name.
It's great that we can fix enum at least, but I would prefer a more general solution that could be applied to any private type.

But it is a clever workaround.

[sdogruyol]

Can we merge this for now and add a TODO for a better version in the future?

[asterite]

I think private types were a mistake, mostly because of problems like this one. private methods are fine, though. So I'll close this and then propose removing private types from the language.

[makenowjust]

@asterite I don't think private types are evil. Crystal has no access control over package and string based macro is wrong. Crystal features are not enough to use private types comfortably.

[asterite]

They are not evil, they just don't work well with other features. That means they weren't thought through, and it's better to remove them than to have a broken feature. Also Ruby and Python don't have visibility modifiers for types and they work fine.

[bcardiff]

I think private types should just have a name that the user won't be able to type and make it imposible to reopen outside the file. With that the metaprograming type expansion will work. I see them as like annonymous type of other languages.

At the end of the day private methods are also obfuscated method names.