Roger,
I experimented with the import name (rather than dot import), and came up with
this:
type Order struct {
sync.RWMutex
Instrument
Id OrderID
ExchangeId string
Price n.Fixed
Side
Quantity n.Fixed
Remaining n.Fixed
OrderType
OrderState
RejectReason string
}
But I’m still not sure it’s great. The n (number) has some meaning, and it
definitely reads easier than fixed.Fixed, but I what I’m really trying to
convey is that “Fixed” is a top-level type, on equal footing with ‘string’.
OrderID is declared in this package, so it reads with the desired simplicity,
and it just seems wrong that I can’t declare Fixed to have the same treatment
just because it comes from another package.
Anyway, I’ve read through your proposal, and I didn’t even think it was
possible… :)
I thought the last segment needed to match the package name. What would be the
rationale for not having that be the case (i.e. why is that even supported ?)
> On Dec 2, 2018, at 12:33 PM, roger peppe <rogpe...@gmail.com> wrote:
>
> > Do you really think you are losing information if this becomes:
> >
> > func matches(p Policy, a authorizer.Attributes) bool {
>
> From my point of view, yes it makes a big difference if I see a
> package-qualified identifier, because I know that it's invoking some other
> package's abstraction. I am very often traversing some code that I am not
> familiar with, and arbitrary names imported from external packages make that
> harder. It also makes it significantly harder to refactor code.
>
> In short, although there is a cost to qualifying external names, I believe
> that cost is justified.
>
> If you wish to lower the overhead of package qualifiers for frequently used
> names, there are alternatives to dot imports. You could specify a short (one
> or two character) identifier instead of the default package name. We do this
> a lot for some DSL-like packages. You could also define local type aliases -
> e.g. type policy = abac.Policy, or local function wrappers (mid-stack
> inlining should make that zero-cost at some point).
>
> FYI I have created a Go proposal related to this that you might wish to give
> feedback on:
> https://github.com/golang/go/issues/29036#issuecomment-443311975
> <https://github.com/golang/go/issues/29036#issuecomment-443311975>
>
> On Sun, 2 Dec 2018, 5:59 am robert engels <reng...@ix.netcom.com
> <mailto:reng...@ix.netcom.com> wrote:
> As some supporting evidence, here is a method signature in k8s:
>
> func matches(p abac.Policy, a authorizer.Attributes) bool {
>
> The interesting aspect is that this method is in package abac, except it is
> in pkg/auth/authorizer/abac
>
> and the one being used in the method
>
> pkg/apis/abac
>
> Do you really think you are losing information if this becomes:
>
> func matches(p Policy, a authorizer.Attributes) bool {
>
> The developer needs to do mental work in either case. I left the authorizer
> on purpose, because Attributes is too generic to be useful. Granted, their
> package structure seems poor in my opinion, but you can’t talk bad about k8s.
>
> Here’s an easier example from k8s:
>
> func (dsc *DaemonSetsController) enqueueDaemonSetAfter(obj interface{}, after
> time.Duration) {
>
> Is that any better than
>
> func (dsc *DaemonSetsController) enqueueDaemonSetAfter(obj interface{}, after
> Duration) {
>
> And another:
>
> func deleteOwnerRefStrategicMergePatch(dependentUID types.UID, ownerUIDs
> ...types.UID) []byte {
>
> Is that really better than:
>
> func deleteOwnerRefStrategicMergePatch(dependentUID UID, ownerUIDs ...UID)
> []byte {
>
>
> If you need a package named types, it is probably ubiquitous throughout the
> codebase, so using type.UID everyplace is just noise.
>
> And probably the most common method signature of them all:
> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
> are you losing anything if this is:
> http.HandleFunc("/bar", func(w ResponseWriter, r *Request) {
> I would argue you are actually gaining something, as the Request above might
> be a facade with extra properties etc. The compiler will inform you if you
> use an incorrect property, and an IDE will give you the method/properties as
> you code, so its completely safe. Now, you might be thinking, request is
> pretty generic, so this is not the best example (because a web app probably
> has lots of different types of Request, and it could quickly become
> confusing, but wait, the http.HandleFunc removes any ambiguity.
>
> All coding requires good development choices - there are many times it
> probably shouldn’t be used - but I making a blanket statement its bad seems
> like overreach.
>
>
>> On Dec 1, 2018, at 11:19 PM, Robert Engels <reng...@ix.netcom.com
>> <mailto:reng...@ix.netcom.com>> wrote:
>>
>> I know everyone hates it when I reference java but it has had dot imports at
>> the package level since day one. I won’t repeat why that matters. It’s never
>> been a problem.
>>
>> I don’t think I ever heard someone complain it was a problem in working in
>> Java, why is it such a problem in Go? I’m suspecting it’s because people’s
>> packages are too large in scope so they end importing tons of external
>> packages. It’s a structure problem not a language feature problem.
>>
>>> On Dec 1, 2018, at 11:08 PM, Ian Denhardt <i...@zenhack.net
>>> <mailto:i...@zenhack.net>> wrote:
>>>
>>> Quoting Robert Engels (2018-12-01 22:25:06)
>>>
>>>> The way to fix it though it just to use dot imports, and encourage it!
>>>> The only time dot imports don't work is when there isn't package
>>>> stutter. Seems like a no brainer and you get the best of both worlds.
>>>
>>> My experience in every language I've worked with that has an equivalent
>>> of dot imports has been: this is more trouble than it's worth. It hurts
>>> readability of large codebases more than any other single language
>>> feature I can think of, and this has been my experience in everything
>>> from Python to Haskell.
>>>
>>> It is sometimes nice for DSLs -- Elm has an Html module that just
>>> defines a function per html element, and folks usually "dot import"
>>> that whole module. But they basically never "dot import" *anything*
>>> else, and doing it in the general case is similarly discouraged. In
>>> languages where I've seen *common* use of it, I've come to the
>>> conclusion that it basically doesn't scale beyond one package, which
>>> has to be something that everyone in the language community knows well.
>>> In Elm it's Html. In Go it's the set of built-in identifiers. That's all
>>> we get.
>>>
>>> ---
>>>
>>> There really is something special about a package's "main" type here
>>> (when it has one) that makes the stutter a bit hard to work around
>>> sometimes. It's a bit unfortunate to have to write context.Context, but
>>> nothing *else* in the context package has this problem. Much of the
>>> OCaml community has gone with the convention of just calling the type
>>> 't' and using the module name to distinguish, and it works pretty well.
>>>
>>> In Elm you see a lot of this:
>>>
>>> import Json.Decoder exposing (Decoder)
>>>
>>> ..which imports the Decoder type from that module unqualified, and
>>> leaves the rest qualified.
>>>
>>> I find it a bit unfortunate that the stuttery approach to naming primary
>>> times has ended up being the norm in Go, but I do think idiom is worth
>>> something; doing pkg.T is a little surprising to me when reading Go
>>> code, even though it isn't when reading OCaml.
>>>
>>>> People say, it makes things less clear, and I counter that variable
>>>> inference is far worse and it's done for the sake of less verbosity,
>>>> and people love it...
>>>
>>> I don't think we're going to agree on this point any time soon, so I'll
>>> just say: this does not square with my own experience.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to golang-nuts+unsubscr...@googlegroups.com
>>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>>> For more options, visit https://groups.google.com/d/optout
>>> <https://groups.google.com/d/optout>.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout
>> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
