On Mon, 3 Dec 2018 at 07:40, robert engels <reng...@ix.netcom.com> wrote:
> 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’.
But it really *isn't* a top-level type on an equal footing with string.
Type "string" is defined by the language and is common with every other Go
program in existence. Your "Fixed" type may be one of many implementations,
each with its own particular set of operations and conventions.
That said, you could do:
type fixed = fixed.Fixed
> 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.
Knowing which things come from external packages is an important part of
understanding the code.
BTW I wonder if a single capital letter might work well for single letter
import identifiers, because that's a space that's not commonly used (with
the exception of the "C" pseudo import). e.g. N.Fixed. Then it wouldn't
clash with commonly used single letter identifiers such as "n".
> 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 ?)
Trivially, every "main" package has this issue, as does any package with a
trailing major version (e.g. google.golang.org/api/compute/v1,
gopkg.in/yaml.v2, cloud.google.com/go/container/apiv1). There are quite a
few packages that use a punctuation-separated last component (e.g.
github.com/juju/persistent-cookiejar, code.google.com/p/biogo.llrb) and
others that just seem to use a different identifier anyway (e.g.
upspin.io/pack/eeintegrity has name "ei" not "eeintegrity").
I don't think it's a good idea to encapsulate some of the above conventions
in the language spec; better just to define a simple rule and an easy way
to get around it when it doesn't fit, I think.
cheers,
rog.
PS embedding Mutex into a public is generally considered not to be a good
idea, as it means that external code can break mutex invariants. It's
considered better to keep mutex-manipulating code encapsulated inside
methods or functions - that way, all lock manipulations can easily be
audited.
--
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.
